On Sat, Apr 09, 2016 at 11:26:23AM +0100, Alex Bligh wrote:
>
> On 9 Apr 2016, at 11:11, Wouter Verhelst <[email protected]> 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
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532
_______________________________________________
Nbd-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nbd-general
