On Sat, Apr 09, 2016 at 11:26:23AM +0100, Alex Bligh wrote: > > On 9 Apr 2016, at 11:11, Wouter Verhelst <w...@uter.be> 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