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

On Sep 22, 2014, at 1:21 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> On Mon, Sep 22, 2014 at 10:44 AM, Jason Greene <jason.greene@redhat.com> wrote:
> 
> 
>> Ok but then if you wait on HTTP/3, 9.2.2 then precludes your ability to select a more modern cipher category like the Aero example. So it doesn’t seem to really meet the former case, and it certainly doesn’t meet the latter.
> 
> I don't think that's true. 9.2.2 doesn't say you can't do non-AEAD. It says
> that you can't do stream or block. Rather:
> 
> "Clients MUST accept DHE sizes of up to 4096 bits. HTTP MUST NOT be used with cipher suites that use stream or block ciphers. Authenticated Encryption with Additional Data (AEAD) modes, such as the Galois Counter Model (GCM) mode for AES [RFC5288] are acceptable."
> 
> I would assume that any new cipher spec would come with a "this is OK for
> HTTP2" bit (or not). So I don't see the interop problem.

It does, but only for today. My wondering could be more precise though. In your hypothetical future example, AEAD is no longer “modern”, but Aero is. Until HTTP/3 is released, HTTP/2 at that time will not meet your first case [1], since AEAD would still be acceptable by the rules of 9.2.2. Granted, the TLS stack if recent in the future hypothetical can and should still pick Aero, just like it can and should pick AEAD today, without 9.2.2.

Put another way, 9.2.2 is a temporary social hack.


[1] "We're kind of sad that people use algorithm X and we wish they would do something more modern”



--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

Received on Monday, 22 September 2014 19:01:06 UTC