From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42078) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XfNaP-0005gz-Bp for qemu-devel@nongnu.org; Sat, 18 Oct 2014 02:34:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XfNaK-0004KS-Q3 for qemu-devel@nongnu.org; Sat, 18 Oct 2014 02:33:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44162) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XfNaK-0004Js-JK for qemu-devel@nongnu.org; Sat, 18 Oct 2014 02:33:52 -0400 Date: Sat, 18 Oct 2014 07:33:22 +0100 From: "Richard W.M. Jones" Message-ID: <20141018063322.GC1349@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141017220323.GC31287@grep.be> Subject: Re: [Qemu-devel] spec, RFC: TLS support for NBD List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wouter Verhelst Cc: Florian Weimer , Hani Benhabiles , libvir-list@redhat.com, mprivozn@redhat.com, nbd-general@lists.sf.net, qemu-devel@nongnu.org, Max Reitz , Stefan Hajnoczi , nick@bytemark.co.uk, Paolo Bonzini On Sat, Oct 18, 2014 at 12:03:23AM +0200, Wouter Verhelst wrote: > Hi all, > > (added rjones from nbdkit fame -- hi there) [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] > 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). > > 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, ...) > > -- > It is easy to love a country that is famous for chocolate and beer > > -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW