From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36648) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xg9hu-00018F-PN for qemu-devel@nongnu.org; Mon, 20 Oct 2014 05:57:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xg9ho-0006YR-Ko for qemu-devel@nongnu.org; Mon, 20 Oct 2014 05:56:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35637) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xg9ho-0006YF-Cl for qemu-devel@nongnu.org; Mon, 20 Oct 2014 05:56:48 -0400 Date: Mon, 20 Oct 2014 10:56:21 +0100 From: Stefan Hajnoczi Message-ID: <20141020095621.GA28515@stefanha-thinkpad.redhat.com> 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> <20141017220323.GC31287@grep.be> <20141018063322.GC1349@redhat.com> <20141020075814.GB19687@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline In-Reply-To: <20141020075814.GB19687@redhat.com> Subject: Re: [Qemu-devel] spec, RFC: TLS support for NBD List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Florian Weimer , "Richard W.M. Jones" , libvir-list@redhat.com, mprivozn@redhat.com, nbd-general@lists.sf.net, nick@bytemark.co.uk, qemu-devel@nongnu.org, Max Reitz , Hani Benhabiles , Paolo Bonzini , Wouter Verhelst --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 20, 2014 at 08:58:14AM +0100, Daniel P. Berrange wrote: > On Sat, Oct 18, 2014 at 07:33:22AM +0100, Richard W.M. Jones wrote: > > On Sat, Oct 18, 2014 at 12:03:23AM +0200, Wouter Verhelst wrote: > > > Hi all, > > >=20 > > > (added rjones from nbdkit fame -- hi there) > >=20 > > [I'm happy to implement whatever you come up with, but I've added > > Florian Weimer to CC who is part of Red Hat's product security group] > >=20 > > > So I think the following would make sense to allow TLS in NBD. > > >=20 > > > This would extend the newstyle negotiation by adding two options (i.e= =2E, > > > client requests), one server reply, and one server error as well as > > > extend one existing reply, in the following manner: > > >=20 > > > - 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: > > >=20 > > > 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 > IMHO the server should never provide *any* information about the exported > volume(s) until the TLS layer has been fully setup. ie we shouldn't only > think about the actual block data transfers, we should protect the entire > NBD protocol even metadata related operations. This makes sense. TLS is about the transport, not about a particular NBD export. The only thing that should be communicated is STARTTLS. Stefan --y0ulUmNC+osPPQO6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJURNxFAAoJEJykq7OBq3PI5LUH/3zQk70+0Rws4riP215tafDU yL9ZFhDGKZMG7fCIF676tajgy5AI+JIlWLYIr+8UI6v7DG8yCw11SxfmiD8TncyN BfCkjfkOAq+tYlGJiaP+uHnMwhP7R4FhIUydj7JMKYPP+1Gg7lGo12YQK8lMjorj fvmHwOqCRtjM+2UJ4GvmTMOwZbL6PEnvweQiOF3iGT1DT0iExMdtqFVS6R8jicFG DIIDf/e4qlGCszBHVRKwtq+IJQjoQCzC/RuxAUP9wNNKZohHniCftPA0g2L8GD7j nmvonEvhpA7rVorqUgcI07kxtLgKgN3l09JTpqEKBg3sVTvapJQK/HkAa0cXIcg= =Opgo -----END PGP SIGNATURE----- --y0ulUmNC+osPPQO6--