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

On Thu, Sep 18, 2014 at 09:33:15AM +0100, Cory Benfield wrote:
> I, a user-agent provider, am
> just as responsible as you to ensure good web citizenship. If hyper
> connects to Jetty, does the ALPN handshake, and then finds a block
> cipher has been negotiated, I am just as responsible as you for
> tearing that connection down. The correct statement here is that "good
> web citizens" are responsible for holding "bad web citizens" to
> account.

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.

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!

Just like Roy, I won't implement any such control and will leave it to
the admin to configure the proper ciphers for this, because this is the
correct thing to do.

Willy

Received on Friday, 19 September 2014 06:08:47 UTC