From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43907) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aoqCu-0004JY-49 for qemu-devel@nongnu.org; Sat, 09 Apr 2016 06:33:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aoqCp-0001u1-4q for qemu-devel@nongnu.org; Sat, 09 Apr 2016 06:33:36 -0400 Received: from barbershop.grep.be ([89.106.240.122]:55360) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aoqCo-0001tv-VM for qemu-devel@nongnu.org; Sat, 09 Apr 2016 06:33:31 -0400 Date: Sat, 9 Apr 2016 12:33:18 +0200 From: Wouter Verhelst Message-ID: <20160409103318.GN19023@grep.be> References: <1460028959-59091-1-git-send-email-alex@alex.org.uk> <20160409093656.GE19023@grep.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [Nbd] [PATCH] Improve documentation for TLS List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Bligh Cc: "nbd-general@lists.sourceforge.net" , "Daniel P. Berrange" , "qemu-devel@nongnu.org" 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