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

[Eric Rescorla <[e-mail]>]

On Mon, Sep 22, 2014 at 10:44 AM, Jason Greene <[e-mail]>
wrote:

>
> On Sep 22, 2014, at 12:29 PM, Eric Rescorla <[e-mail]> wrote:
>
> >
> >
> > On Mon, Sep 22, 2014 at 9:41 AM, Jason Greene <[e-mail]>
> wrote:
> >
> > On Sep 22, 2014, at 11:18 AM, Eric Rescorla <[e-mail]> wrote:
> >
> > >
> > > I don't actually think this is that important an issue either. As I
> understood the discussion
> > > in Zurich, the new TLS limitations were directed towards pulling users
> of HTTP2 towards
> > > modern algorithms. However, algorithms which have serious weaknesses
> should probably
> > > be deprecated in all versions of HTTP (as with
> https://tools.ietf.org/html/draft-ietf-tls-prohibiting-rc4-00)
> > >
> > > Say we decided that in future we preferred Aero (
> https://tools.ietf.org/html/draft-mcgrew-aero-01)
> > > to AEAD constructions. That seems like something we could roll out in
> HTTP3 but wouldn't
> > > be appropriate to retroactively apply to TLS 1.2 unless there was
> something seriously wrong
> > > with AEAD (and then see above).
> >
> > I think this hypothetical actually counters your point. Every rev of the
> HTTP spec introduces interop cost, therefore having to rev the protocol
> just because TLS needs to rev is unnecessary cost.
> >
> > I think we're talking past each other here. There are two major cases:
> >
> > - We're kind of sad that people use algorithm X and we wish they would
> >    do something more modern.
> > - There is something seriously wrong with algorithm X and people need
> >   transition off it pronto.
> >
> > In the former case, we have pretty limited options, since it's probably
> not
> > worth breaking interop over. So, we can do nothing or we can gradually
> > tell people to upgrade at preexisting protocol upgrade points. I.e., we
> > wouldn't roll out HTTP3 to do this, we'd just do it when we were already
> > rolling out HTTP3 (the same way as 9.2.2 is now). in the second case,
> > we would want to adjust all versions of HTTP so no new rev would be
> > required.
>
> 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.

-Ekr