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

As a concrete example, almost all software and firmware updates are delivered
these days using HTTP (preferably over TLS, of course).  These sites are expected
to deliver updates to systems running obsolete software.  In some cases,
software that hasn't been run at all for five or six years.

When such a site receives a request using an older, now less-secure cipher,
but one that is expected for that type of client, what is the site supposed
to do?  Is it supposed to reject the request if the (perhaps updated) h2
specification says so?  Who does that help?  Obviously, the purpose of the
site is more important than the bad assumptions in 9.2.2.  That's why it
is an admin decision, not a protocol requirement.

There is a reason that TLS doesn't forbid the use of old ciphers, even the
ones that are known to be easily breakable.  Not every application is the
same.  We have BCP documents to explain the nuances of various choices.
When a site chooses to do something against BCP, it is usually because
they either have no idea how TLS is configured (in which case TLS should
be the one selecting the better defaults) or they have deliberately
chosen to configure it for the sake of their own, perhaps unique,
interoperability requirements.  We don't know which.  We don't know why.
And we sure as hell don't know when.

....Roy

Received on Saturday, 20 September 2014 18:54:26 UTC