Re: [Qemu-devel] spec, RFC: TLS support for NBD

["Daniel P. Berrange" <berrange@redhat.com>]

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,
> > 
> > (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).

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.

> >   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: <initiate TLS handshake>
> > 
> >   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, ...)

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|