W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

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

From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 23 Sep 2014 13:12:55 -0700
Message-ID: <CABcZeBMVnjqNOJ82CbuWj8-sgqdv6=+oLmjCE7NeVNVrSqGqsg@mail.gmail.com>
To: Greg Wilkins <gregw@intalio.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Mark Nottingham <mnot@mnot.net>, Jason Greene <jason.greene@redhat.com>, Patrick McManus <pmcmanus@mozilla.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Sep 23, 2014 at 11:27 AM, Greg Wilkins <gregw@intalio.com> wrote:

>
>
>
> On 23 September 2014 18:06, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>
>> That is precisely what 9.2.2. does:
>>
>> * MUST ephemeral
>>
>> * MUST NOT block or stream cipher
>>
> but it also lists exceptions for ciphers like AES GCM, which is a block
> cipher.
>

As far as TLS is concerned, AES-GCM is not a block cipher [0] It is an AEAD
cipher. This is pretty clear in the specification:

   This document describes the use of AES [AES
<https://tools.ietf.org/html/rfc5288#ref-AES>] in Galois Counter Mode
   (GCM) [GCM <https://tools.ietf.org/html/rfc5288#ref-GCM>] (AES-GCM)
with various key exchange mechanisms as a
   cipher suite for TLS.  AES-GCM is an authenticated encryption with
   associated data (AEAD) cipher (as defined in TLS 1.2 [RFC5246
<https://tools.ietf.org/html/rfc5246>])
   providing both confidentiality and data origin authentication.


https://tools.ietf.org/html/rfc5288#section-1


Also this language does not help you if all you have is the cipher name.
> Unless we create an IANA register of h2 (un)acceptable cipher names
>

I don't believe that this is correct. As I said earlier, TLS categorizes
ciphers
by type, and so once you have the ciphersuite definition you know if it's
block, stream, or aead.

-Ekr



>
> On 23 September 2014 19:16, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>
>> > One thing that I’ve heard is requiring clients to offer the “good”
>> suites first, to promote interop. Does anyone see a downside to doing that?
>>
>> It would definitely solve Greg's issue with Java <= 7.
>>
>
> Sorry but it does not help at all.   An ordered array with an undeclared
> break between good and bad ciphers still needs the server to be able to run
> an isAcceptableToH2 method to determine the break.  If I have that method,
> then ordering is not necessary.
>
> There are two problems here - one is the debate about if we should be
> doing TLS restrictions in the first place.   The other is about designing a
> good handshake.  Currently the handshake is not a good design and relies on
> expected evolution of ciphers into the future an norms of configuration to
> make it work.      If the spec at least designed a handshake that was
> robust, I would be a lot less strident about my opposition to this social
> engineering experiment.
>
>
> regards
>
>
>
>
>
> --
> Greg Wilkins <gregw@intalio.com>
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
> scales
> http://www.webtide.com  advice and support for jetty and cometd.
>
Received on Tuesday, 23 September 2014 20:14:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 9 September 2019 17:48:21 UTC