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

[Wouter Verhelst <w@uter.be>]

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