Re: Discussion of 9.2.2

Mark,

I am just incredulous that the position adopted appears to be that we know
the fragile handshake will not break in the future because we know how
ciphers will evolve and be deployed in the future.

If the defence of the status quo was not based on such weak foundations or
less intolerant of any change, then perhaps we'd burn less cycles.

the fundamental issue as I see it is that we have designed a fragile
handshake, that if implementations have slightly different interpretations
of 9.2.2 results in communications failure. This was discovered by a real
interop problem albeit from a very poor implementation of 9.2.2 on my
behalf.

So aside from the social argument of should we be doing this or not, I fail
to understand why this WG is rejecting the valid feedback that the
handshake is fragile.     Arguments that are based on predictions of the
evolutions of ciphers for the next few decades to combat the fragility of
the handshake are themselves fragile - no matter how smart the people are
who are making them.

regards










On 24 September 2014 21:17, Mark Nottingham <mnot@mnot.net> wrote:

> We’re burning a lot of cycles on the TLS cipher suite requirements, and
> producing much heat but little light. Discussion seems to be looping, in
> part because people either aren’t reading the current spec language, or are
> drawing the wrong conclusions from it.
>
> The actual requirements there are:
>
> 1) HTTP/2 MUST only be used with cipher suites that have ephemeral key
> exchange [plus details].
> 2) HTTP MUST NOT be used with cipher suites that use stream or block
> ciphers.
> 3) Clients MAY advertise support of cipher suites that are prohibited by
> the above restrictions in order to allow for connection to servers that do
> not support HTTP/2.
>
> <http://http2.github.io/http2-spec/#rfc.section.9.2.2>
>
> Further discussion needs to be directly related to this text — if you draw
> conclusions, please do so by illustrating how THESE requirements will
> result in an interop problem.
>
> As discussed, the TLS WG has been consulted on the current text; there is
> not a process problem inherent here. Furthermore, an implementation
> roadblock in a single platform, while unfortunate, is not grounds for
> changing the protocol on its own.
>
> That being the case, those who still think we have a problem need to
> convince the rest of the WG that this is the case — so far, I don’t see
> that happening.
>
> —
>
> My personal observations (no chair hat):
>
> AIUI, the crux of the purported problem is when a new cipher suite X is
> introduced, and a client offers it. If the server supports that cipher
> suite but the HTTP/2 implementation has not decided that it is conformant
> to these requirements, INADEQUATE_SECURITY will be thrown.
>
> It seems to me that a few editorial changes would help here.
>
> a) Explicitly note that INADEQUATE_SECURITY is thrown in 9.2.2 (it’s
> implied by 9.2 but let’s be explicit). This should happen regardless.
> b) Change the start of #2 above to “HTTP/2”. This should happen regardless.
> c) Change #2 above to “HTTP/2 MUST NOT be used with cipher suites that are
> known to be stream or block ciphers.” This emphasises that it’s a
> blacklist, not a whitelist, and avoids throwing INADEQUATE_SECURITY when
> encountering a cipher suite with unknown properties.
>
> Regards,
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
>


-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.