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

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