Re: Discussion of 9.2.2

[Greg Wilkins <[e-mail]>]

On 28 September 2014 01:58, Martin Nilsson <[e-mail]> wrote:

> Do you believe we will intentionally release a new cipher that isn't
> strong enough to be acceptable for HTTP/2? If no, then there isn't a
> problem here.


That is not the failure mode that we have been talking about.

It is not that the new keys are likely to be weak.  It is in fact because
they are almost certainly going to be strong, but might not match the 9.2.2
description of what a strong cipher is.

Repeated description of the issue follows... please skip if you have got it.

Once you have string keys that don't clearly fit the 9.2.2 description of
what string is,  then you get problems because the handshake is fragile and
depends on non ambiguous interpretation of 9.2.2 to work out which ciphers
are only there for h1 fallback.

If such new ciphers come along, implementations of 9.2.2 will need to be
revised and as those implementations are rolled out, we will have interop
failures because some servers will wrongly assume that a new strong 9.2.2
dubious cipher is being offered for h2 by an updated client when it is in
fact being offered as a h1 fallback cipher.

Ie are we 100% certain that all future strong ciphers will pass:
isEphemeral() && !isBlock() && !isStream()?    What about the alternate
implementation of this that we have seen in FF of isEphemeral() && isAEAD()
- will that be true for all strong ciphers for the life of h2?

Nobody has yet said why we cannot just make the handshake non-fragile.
I've offered several suggestion for that:
 a) white list of know h1 fallback ciphers
 b) update ALPN to indicate which ciphers are acceptable for each offered
protocol
 c) do a h1 only retry handshake
 d) move the  9.2.2 requirement that applies equally to h1 and h2





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