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