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

On Tue, Sep 23, 2014 at 01:11:16AM -0700, Eric Rescorla wrote:
> 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.

Maybe that's what it means for people who are expert in this area, but
when I read this for example :

   HTTP/2 MUST only be used with cipher suites that have
   ephemeral key exchange, such as the ephemeral Diffie-Hellman (DHE)
   [TLS12] or the elliptic curve variant (ECDHE) [RFC4492].

I'm not seeing exclusion of various broken things, just restriction to
a specific mode. Don't get me wrong, I'm clearly not skilled in this
area, and my unwise eye reads this as "must implement either DHE or
ECDHE". I don't know if right now there are alternatives that must be
avoided, just like I don't know when reading this if a future solution
will be acceptable or not. Thus my point was that it could be reworded
against the solutions that are not acceptable instead (if such exist).
For example :

   HTTP/2 MUST NOT be used with cipher suites that do not have ephemeral
   key exchange, such as XYZ.

Similarly, I'm seeing this :

   Clients MUST accept DHE sizes of up to 4096 bits.

This means to me that DHE must always be supported. What if in the
future we consider DHE not to be acceptable anymore ? There will be
a conflict. Isn't it better to say something like :

   Clients implementing DHE MUST accept sizes of up to 4096 bits.

(I don't know if there are alternatives to DHE).

And the last one :

   To avoid this problem, implementations of HTTP/2 that use
   TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
   [TLS-ECDHE] with P256 [FIPS186].

Is this the only acceptable cipher for TLS 1.2 or are there stronger
ones that are acceptable as well ? If the latter, the sentence above
forces avery implementation to support at least this one, even five
years away when we decide to obsolete it despite other ciphers still
being acceptable for TLS 1.2.

I know that the point is about ensuring that communications are made
over a reasonably safe channel, but for the unaware people configuring
the ciphersuite in their servers, it's really not easy to tell which
one is eligible and which one is not. All we know is that the ciphersuite
must at least include the examples above to ensure interoperability, but
we don't know if other ones are safe, just like we don't have any hints
what to chose when the ones above are obsoleted.

Maybe we could even have an exhaustive list in the spec of all the ciphers
that are not acceptable at the time of writing. This would significantly
help admins to validate their setups and refine the cipher suite if they
find them. Just a guess, I don't even know if that's possible to enumerate
them all.

Thanks,
Willy

Received on Tuesday, 23 September 2014 08:29:49 UTC