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

On Mon, Sep 22, 2014 at 12:00 PM, Jason Greene <jason.greene@redhat.com>
wrote:

>
> 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.
>

That's my understanding of the situation, yes.

-Ekr


>
> [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
>
>