From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44548) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aoqHw-00045Q-PM for qemu-devel@nongnu.org; Sat, 09 Apr 2016 06:38:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aoqHo-0002ew-TG for qemu-devel@nongnu.org; Sat, 09 Apr 2016 06:38:48 -0400 Received: from barbershop.grep.be ([89.106.240.122]:50499) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aoqHo-0002er-O0 for qemu-devel@nongnu.org; Sat, 09 Apr 2016 06:38:40 -0400 Date: Sat, 9 Apr 2016 12:38:28 +0200 From: Wouter Verhelst Message-ID: <20160409103828.GO19023@grep.be> References: <1460053967-65141-1-git-send-email-alex@alex.org.uk> <20160409101117.GI19023@grep.be> <9AD6CFB3-011D-42FF-8652-5BCBF085BE57@alex.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9AD6CFB3-011D-42FF-8652-5BCBF085BE57@alex.org.uk> Subject: Re: [Qemu-devel] [Nbd] [PATCHv3] 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:26:23AM +0100, Alex Bligh wrote: > > On 9 Apr 2016, at 11:11, Wouter Verhelst wrote: > > Since you say zero here, how is it different from OPTIONALTLS? > > > > If "not at all", just drop optional. > > As per previous message, because SELECTIVETLS requires INFO, > but OPTIONALTLS doesn't. Um. So you're suggesting that if a client sends INFO, we're suddenly in a whole different mode of operation? That seems to make little sense (other than "complicate matters for no particularly good reason") > > I'm not *that* well versed in the details of TLS, but isn't it better to > > specify which side should go first? > > I believe it's a design feature that you need not. Essentially both > parties start in a 'no handshake has taken place' state, and on the > first read or write from either end, one party starts the handshake > (and there is a provision in case they collide). Alternatively > either end can explicitly request the handshake. > > There is actually an implementation advantage to the server doing it > (having just written it) which is that the server can then capture > any error (invalid credentials or whatever) and report it with whatever > logging it does for the STARTTLS option; otherwise invalid certificate > responses come with the next option it receives. Okay, fine then. [...] > > [...] > >> +The client MUST NOT issue `NBD_OPT_STARTTLS` unless the server > >> +set flag NBD_FLAG_FIXED_NEWSTYLE and the client replied > >> +with NBD_FLAG_C_FIXED_NEWSTYLE in the fixed newstyle > >> +negotiation. > > > > Why not "unless fixed newstyle negotiation is in effect"? No need to > > repeat that definition. > > Can do; I just wanted to be explicit that both server and client > must support it. Sure, just want to make things not *too* verbose, is all. > > [...] > >> +### Security considerations > >> + > >> +#### TLS versions > >> + > >> +NBD implementations supporting TLS MUST support TLS version 1.2, > >> +SHOULD support any later versions, and MAY support older versions. > > > > I would prefer "SHOULD NOT allow TLS versions older than 1.2" here. > > There are some serious flaws in older TLS versions; currently these are > > still supported by most web browsers for backwards compatibility > > reasons, but that does not apply for us. > > I'd be all for that. Or certainly "SHOULD NOT support LS versions older > than 1.2 by default" Or that. The point is that doing TLS < 1.2 is stupid, especially for a new protocol, so I think we should make it explicit that clients should not try that save in exceptional circumstances. -- < 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