From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60729) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aoFws-0003DL-Rf for qemu-devel@nongnu.org; Thu, 07 Apr 2016 15:50:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aoFwp-00088Y-4x for qemu-devel@nongnu.org; Thu, 07 Apr 2016 15:50:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38596) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aoFwo-00088P-Na for qemu-devel@nongnu.org; Thu, 07 Apr 2016 15:50:35 -0400 References: <1460053967-65141-1-git-send-email-alex@alex.org.uk> From: Eric Blake Message-ID: <5706BA08.40609@redhat.com> Date: Thu, 7 Apr 2016 13:50:32 -0600 MIME-Version: 1.0 In-Reply-To: <1460053967-65141-1-git-send-email-alex@alex.org.uk> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fFvFLuml4622TsV17Ck08L8PtIguQDn7X" Subject: Re: [Qemu-devel] [PATCHv3] Improve documentation for TLS List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Bligh , Wouter Verhelst Cc: "nbd-general@lists.sourceforge.net" , "qemu-devel@nongnu.org" , "Daniel P. Berrange" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fFvFLuml4622TsV17Ck08L8PtIguQDn7X Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/07/2016 12:32 PM, Alex Bligh wrote: > * Call out TLS into a separate section >=20 > * Add details of the TLS protocol itself >=20 > * Emphasise that actual TLS session initiation (i.e. the TLS handshake)= can > be initiated from either side (as required by the TLS standard I beli= eve > and as actually works in practice) >=20 > * Clarify what is a requirement on servers, and what is a requirement o= n > clients, separately, specifying their behaviour in a single place > in the document. >=20 > * Document the four possible modes of operation of a server. >=20 > Signed-off-by: Alex Bligh > --- > doc/proto.md | 341 +++++++++++++++++++++++++++++++++++++++++++++++++++= ++------ > 1 file changed, 307 insertions(+), 34 deletions(-) >=20 > + > +If a client supports TLS, it SHOULD also support the INFO > +extension, and SHOULD use `NBD_OPT_GO` if available in place > +of `NBD_OPT_EXPORT_NAME`. The reason for this is set out in > +the final paragraphs of the sections under 'FORCEDTLS' > +and 'SELECTIVETLS': this gives an opportunity for the > +server to transmit that an error going into transmission > +mode is due to the client's failure to initiate TLS, > +and the fact that the client may obtain information about > +which exports are TLS-only through `NBD_OPT_INFO`. Side note (no change needed to your text): Qemu's initial implementation of TLS in the client is binary (you either want TLS or plaintext; there's no way to connect to a server and then decide whether to upgrade to TLS - a plaintext client will never use TLS of an OPTIONALTLS server). In TLS mode, the client always sends NBD_OPT_STARTTLS first (and gets a sane error message if the server can't/won't use TLS). In plaintext mode, the client always sends NBD_OPT_LIST first - which will get a nice NBD_OPT_ERR_TLS_REQD from a FORCEDTLS server, but does NOT error out for a SELECTIVETLS server. But if it DOES get a listing, it then checks that the desired export was present in the listing, which means a SELECTIVETLS server that requires TLS on the particular export the client was hoping for will cause the client to fail with a graceful error message of "export not present" generated by the client, rather than attempting NBD_OPT_EXPORT_NAME, so long as the SELECTIVETLS server omitted the TLS-only export in its listing. Only for a really old server (such as non-fixed newstyle), where NBD_OPT_LIST cannot be attempted or fails with NBD_OPT_ERR_UNSUP, is the client still in the dark about whether TLS is required, but in that case, the server probably doesn't support TLS (especially since TLS requires fixed newstyle). But the reason I see no need to modify your text: I'm planning on changing qemu's plaintext client to try NBD_OPT_GO rather than NBD_OPT_LIST. For a FORCEDTLS server, the command will fail with NBD_REP_ERR_TLS_REQD (whether or not the server knows NBD_OPT_GO); and for a SELECTIVETLS server, we just mandated that NBD_OPT_GO must be recognized, so it will fail with NBD_REP_ERR_TLS_REQD for a TLS-only export, and will succeed (in plaintext) otherwise. Which means there is no longer a need to fall back to NBD_OPT_LIST. > + > +With regard to the second, any server that does not wish > +to be subject to a potential downgrade attack SHOULD either > +used FORCEDTLS mode, or should force TLS on those exports > +it is concerned about using SELECTIVE mode and TLS-only > +exports. It is not possible to avoid downgrade attacks > +on exports which may be served either via TLS or in plain > +text unless the client insists on TLS. OPTIONALTLS SHOULD NOT > +be used where man-in-the-midle attacks are a concern. s/midle/middle/ > @@ -391,7 +679,10 @@ of the newstyle negotiation. > - `NBD_OPT_LIST` (3) > =20 > Return a number of `NBD_REP_SERVER` replies, one for each export, > - followed by `NBD_REP_ACK`. > + followed by `NBD_REP_ACK`. The server MAY omit entries from this > + list if TLS has not been negotiated and either the server is > + operating in FORCEDTLS mode or the server is operating in > + SELECTIVETLS mode and the entry concerned is a TLS-only export. Not quite right - in FORCEDTLS mode, the server MUST reply with NBD_REP_ERR_TLS_REQD. Correct would be: The server MAY omit entries from this list if TLS has not been negotiated and the server is operating in SELECTIVETLS mode, where the entry concerned is a TLS-only export. Maybe even strengthen it to SHOULD, particularly given my above side note about qemu's usage of NBD_OPT_LIST to determine if a plaintext client is talking to a server that wants TLS. I'm down to just 2 findings and a side comment, which means we're close enough that you can add: Reviewed-by: Eric Blake --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --fFvFLuml4622TsV17Ck08L8PtIguQDn7X Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJXBroIAAoJEKeha0olJ0Nq7pgH/j09VkRuS5ye2DpGcOYs4Rcp AKIYFoe82VR39ajFohG+hEhhtrKMS4w7PbbzljMgTATRsHoHqB4YAAHLFk9rdApB EDy5yCmLI+HsvsEcc0v87WrtZdq3CJ/j/QOBj8FwSWCQ4SIqgtH5cID0dnG1mNKe CDlwpP31tgQMGVkgFzvMBmyP4piuYnXdacIIpuKh1Y357F0Q8ubvFBf58h0IBS7g Z8aVZql4lxyHbyHucGCYEgLacyumoefAAiqJLshgPWtuFZexePN7Qeg7o6Jnai4t BmCBXJyE7iEogMENOof59RKYf3VVr/RCKiPFmFKHQxePI+7+yQQ4xG7ON8D2yHo= =wc+z -----END PGP SIGNATURE----- --fFvFLuml4622TsV17Ck08L8PtIguQDn7X--