Re: 9.2.2 Cipher fallback and FF<->Jetty interop problem

On Thu, Sep 4, 2014 at 9:05 PM, Greg Wilkins <gregw@intalio.com> wrote:

>
>
> The connection is negotiated as  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, which
> would be acceptable if the protocol was https, but because it is h2,  FF
> fails the connection due to lack of AEAD.     This results in a connection
> failure on the client, when it would have worked fine if http/1.1 was
> accepted as the protocol instead.
>

right. h2-14 requires aead and the server selected h2 via alpn without also
using aead - so that's a h2 level protocol error on the server's part and
that connection can't proceed. The expected thing would have been for the
server not to select h2.

The question of what to do next in the client is tricky and fun to talk
about, but I think the standard does the right thing by steering clear of
it. As you note, firefox right now declares game over - hard fail. No doubt
the error page for it is in dire need of improvement :)

One part of that decision is the nature of the specific failure - auto
fallback to a less secure suite from a server that indicated it was capable
of a stronger suite (by signaling h2) has the hallmarks of a downgrade
attack. scary stuff.

The other part of that is just design experience that favors being
intolerant of errors - especially at early stages. These workarounds tend
to get added over time for bugwards compatibility,, but at this stage we
shouldn't feel that kind of pressure - its much more important to build an
ecosystem where things operate correctly when its full of those kinds of
written and unwritten rules. A lot of folks believe we're in an era where
"be liberal in what you receive" is no longer in the best interest of the
Internet.

I do agree this is tricky to get right (but worthwhile!). We had a bug
where we would occasionally send a TLS 1.0 client hello (due to some tls
intolerance logic) with h2 in the offer list. If h2 was selected, we
generated an error. We shouldn't do that - they aren't compatible.