From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47912) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XfFcj-0005bz-Kv for qemu-devel@nongnu.org; Fri, 17 Oct 2014 18:03:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XfFcc-0000SV-1H for qemu-devel@nongnu.org; Fri, 17 Oct 2014 18:03:49 -0400 Received: from barbershop.grep.be ([89.106.240.122]:51074) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XfFcb-0000Pg-S7 for qemu-devel@nongnu.org; Fri, 17 Oct 2014 18:03:41 -0400 Date: Sat, 18 Oct 2014 00:03:23 +0200 From: Wouter Verhelst Message-ID: <20141017220323.GC31287@grep.be> References: <20140903164417.GA32748@stefanha-thinkpad.redhat.com> <20140905084618.GA3720@Inspiron-3521> <20140905132608.GB26974@grep.be> <20141001202326.GA2533@grep.be> <20141002110516.GG13032@redhat.com> <542D36E8.2010705@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oLBj+sq0vYjzfsbl" Content-Disposition: inline In-Reply-To: <542D36E8.2010705@redhat.com> Subject: [Qemu-devel] spec, RFC: TLS support for NBD List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , "Daniel P. Berrange" , Hani Benhabiles , Stefan Hajnoczi , qemu-devel@nongnu.org, Max Reitz , nick@bytemark.co.uk, libvir-list@redhat.com, mprivozn@redhat.com, nbd-general@lists.sf.net, rjones@redhat.com --oLBj+sq0vYjzfsbl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, (added rjones from nbdkit fame -- hi there) So I think the following would make sense to allow TLS in NBD. This would extend the newstyle negotiation by adding two options (i.e., client requests), one server reply, and one server error as well as extend one existing reply, in the following manner: - The two new commands are NBD_OPT_PEEK_EXPORT and NBD_OPT_STARTTLS. The former would be used to verify if the server will do TLS for a given export: C: NBD_OPT_PEEK_EXPORT S: NBD_REP_SERVER, with an extra field after the export name containing flags that describe the export (R/O vs R/W state, whether TLS is allowed and/or required). =20 If the server indicates that TLS is allowed, the client may now issue NBD_OPT_STARTTLS: C: NBD_OPT_STARTTLS S: NBD_REP_STARTTLS # or NBD_REP_ERR_POLICY, if unwilling C: Once the TLS handshake has completed, negotiation should continue over the secure channel. The client should initiate that by sending an NBD_OPT_* message. - The server may reply to any and all negotiation request with NBD_REP_ERR_TLS_REQD if it does not want to do anything without TLS. However, if at least one export is supported without encryption, the server must not in any case use this reply. There is no command to "exit" TLS again. I don't think that makes sense, but I could be persuaded otherwise with sound technical arguments. Thoughts? (full spec (with numbers etc) exists as an (uncommitted) diff to doc/proto.txt on my laptop, ...) --=20 It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 --oLBj+sq0vYjzfsbl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUQZIqAAoJEMKUD5Ub3wqd3jsP/R2A6uVxUoGgZO1espqzp43S 116j1tRazUESSjZ2RDTiRkPOnmXvL17oGMAwzUWARS8dqEq/LThOPSiFFHwICnfz e950HUE6UTndUeJMpbLd2UkXBBVba3opcsqU8TAnCN6bN5c5qFRrQaVjzZsDuk6t 4Qz9XHVrWpJeL/NHmmOFPAvWc2cC31vxdxDDJVxNMeIxWcZxCgwFsAVbvRpgWjgB xrFZ4sPS4aqcKgmRoPbtUHRgfKI6eX9X3UptAdQPJY3+aCkFV7O4ZOQt0uVCWlkj CqAJwzPbawRyByjuHXgReRD1RkyKUyrpIUPpT2QT2IYpiC495JF/bPrdjgO/h6uh +XTlW2wEvc1QmKQ2fcwl2j22O0DbYI+y98J2/E9f3s+AfDDl37KEZXIg3dVr2Xby e9Nf9ebHpN8FLzO65r30Awlbu/RBJjLJobZx+VuH910xuv06oceoqEHKQKbAFzCn 2ei/aMRIWIjPyi50VObobTzB0iLV9C6ijSC5ppq82Xku1Xs5b4VJqzsvqAlImq1R rU5zsAGvgeRp5CUszql3c/iivYUyZgIzNeo+epC+VqFjAjWKRJSFss2NiLtT9hfi 3FA4YzgluotxleINzRXbm1MEmHD6MR11fwTMVujjip+nxfFNG3sjs3wt+vB0+Kqw ugZLazS2elcKgemO4CHE =mf12 -----END PGP SIGNATURE----- --oLBj+sq0vYjzfsbl--