Re: [Qemu-devel] [Nbd] [PATCH] Improve documentation for TLS

[Wouter Verhelst <w@uter.be>]

On Sat, Apr 09, 2016 at 11:04:09AM +0100, Alex Bligh wrote:
[...]
> > [...]
> >> +The server MUST NOT send `NBD_REP_ERR_TLS_REQD` in reply to
> >> +any command if TLS has already been neogitated. The server
> > 
> > negotiated
> 
> I'd make sure you're looking at the latest version as Eagle Eyed Eric
> pointed out a whole pile of these.

Yeah, I noticed :-)

> > [...]
> >> +The client MAY send `NBD_OPT_STARTTLS` at any time to initiate
> >> +a TLS session, except that the client MUST NOT send
> >> +`NBD_OPT_STARTTLS` if TLS has alreay been initiated. If the
> >> +cllient receives `NBD_REP_ACK` in response, it
> >> +MUST immediately upgrade the connection to TLS. If it receives
> >> +`NBD_ERR_REP_UNSUP` in response or any other error, it indicates
> >> +that the server cannot or will not upgrade the connection to
> >> +TLS and therefore MUST either continue the connection without
> >> +TLS, or discconnect.
> > 
> > That, or NBD_REP_ERR_POLICY.
> 
> Yeah I can make that an alternative.

POLICY is the correct message; UNSUP is the alternative ;-)

(as in "for backwards compatibility, a client should also be prepared...")

[...]
> > (actually, "any error". If STARTTLS errors, the server effectively does
> > not support TLS)
> 
> Well NBD_REP_ERR_INVALID means "The option sent by the client is known by
> this server, but was determined by the server to be syntactically invalid."
> which means the client has done something wrong. Given we've defined the
> legal responses to NBD_OPT_STARTTLS I'd rather keep that one.

Fair enough. Also, INVALID is the correct error message when the client sent
NBD_OPT_STARTTLS while inside a TLS connection, too, so that would've been a
contradiction ;-)

> > [...]
> >> - `NBD_OPT_STARTTLS` (5)
> >> 
> >> -    The client wishes to initiate TLS. If the server replies with
> >> -    `NBD_REP_ACK`, then the client should immediately initiate a TLS
> >> -    handshake and continue the negotiation in the encrypted channel. If
> >> -    the server is unwilling to perform TLS, it should reply with
> >> -    `NBD_REP_ERR_POLICY`. For backwards compatibility, a client should
> >> -    also be prepared to handle `NBD_REP_ERR_UNSUP`. If the client sent
> >> -    along any data with the request, the server should send back
> >> -    `NBD_REP_ERR_INVALID`. The client MUST NOT send this option if
> >> -    it has already negotiated TLS; if the server receives
> >> -    `NBD_OPT_STARTTLS` when TLS has already been negotiated, the server
> >> -    MUST send back `NBD_REP_ERR_INVALID`.
> >> -
> >> -    This functionality has not yet been implemented by the reference
> >> -    implementation, but was implemented by qemu so has been moved out of
> >> -    the "experimental" section.
> >> +    The client wishes to initiate TLS.
> >> +
> >> +    The server MUST either reply with `NBD_REP_ACK` after which
> >> +    point the connection is upgraded to TLS, or reply with
> >> +    `NBD_REP_ERR_UNSUP`.
> > 
> > (or POLICY)
> 
> OK

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12