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

[Cory Benfield <[e-mail]>]

On 19 September 2014 07:08, Willy Tarreau <[e-mail]> wrote:
> I disagree hre, only the admin knows in what context agents are deployed
> and what security level is acceptable/accepted. Browser vendors have no
> idea what usage is made from their product. If I'm using your browser to
> retrieve photos from my low-level weather satellite in space for whom it's
> extremely expensive to use higher crypto, it's *my* problem. And if I set
> up an emergency server to cut the power in a datacenter using a 4096 bit
> key and a cipher that is not supported by 9.2.2 because I feel it's more
> secure than what is currently required, it's my decision as well.

This is a good point. As it turns out I'm covered because I will have
a switch that says "please stop bugging me about ciphers". This will
continue to allow you to do what you want, while having a by-default
behaviour that matches the RFC. Secure-by-default is almost always
better than secure-by-opt-in.

> I've always felt that the H2 spec is walking on the TLS group's feet here.
> Inciting servers to increase their key length has always been done by cert
> vendors, and browsers have always followed this support very early and this
> model has been working for decades now. There's no reason for suddenly
> breaking the net or making it harder to upgrade crypto there because the
> algorithms are written black on white in the layer 7 protocol spec, which
> also supports being transported over a clear medium!

I hadn't considered this, but I agree with this point.

Don't mistake my previous post for an impassioned defense of 9.2.2 in
its current form. I think its *goal* is laudable, not necessarily its
implementation, and if we think we can move the requirement (or
something similar) to the TLS WG I am happy to remove 9.2.2 from the
draft.

Cory