[libvirt] spec, RFC: TLS support for NBD

[Stefan Hajnoczi]

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

This makes sense.

TLS is about the transport, not about a particular NBD export.  The only
thing that should be communicated is STARTTLS.

Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20141020/6e456c3a/attachment-0001.sig>