[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Nbd] [PATCHv3] Improve documentation for TLS
From: |
Wouter Verhelst |
Subject: |
Re: [Qemu-devel] [Nbd] [PATCHv3] Improve documentation for TLS |
Date: |
Sat, 9 Apr 2016 12:38:28 +0200 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On Sat, Apr 09, 2016 at 11:26:23AM +0100, Alex Bligh wrote:
>
> On 9 Apr 2016, at 11:11, Wouter Verhelst <address@hidden> 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