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

On Mon, Sep 22, 2014 at 10:42 PM, Willy Tarreau <w@1wt.eu> wrote:

> Hi Eric,
>
> On Mon, Sep 22, 2014 at 11:21:52AM -0700, Eric Rescorla 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 <http://http2.github.io/http2-spec/#RFC5288>
> > [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.
>
> I think it's not easy to tell what will exist in the future, however we can
> exhaustively list what existing ciphers we don't want to support. Thus,
> shouldn't we instead enumerate a list of properties that are incompatible
> with HTTP/2 ? That would leave the door open for new ciphers. HTTP/1 has
> benefitted from TLS evolutions for almost 20 years, and I would find it
> sad that we have to emit a new HTTP version just to make everyone support
> a new cipher. This is instead a property of the TLS layer and both sides
> upgrade progressively to support new versions.
>

My understanding is that this is what 9.2.2 does.

-Ekr

Regards,
> Willy
>
>