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