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: Fri, 5 Sep 2014 11:13:07 -0700
Message-ID: <CABcZeBPnu4O6c4F1jqfPSwURVfEy8dYkyeCieVeN4vtdU2oZLw@mail.gmail.com>
To: Greg Wilkins <gregw@intalio.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Sep 4, 2014 at 11:46 PM, Greg Wilkins <gregw@intalio.com> wrote:

>
> On 5 September 2014 15:45, Eric Rescorla <ekr@rtfm.com> wrote:
>
>> In TLS, server selects both the ALPN protocol and the cipher suite. I'm
>> not sure
>> what lead you to believe that the client selected the cipher suite, but
>> that's not
>> correct and if you can point me to the section in the TLS spec that made
>> you
>> think that, I'll try to fix it.
>>
>
> I was confused by the state diagrams in 7301 and 5246  that show either
> the server
> or the client can first change the cipher suite.  But then I did not read
> the 5246 in
> detail, so probably not a fair reflection on those documents.
>

Ah, this is a naming problem. That message just means "go to the new cipher
suite". The cipher suites are negotiated in the handshake. Unfortunately, I
don't think we will change the message name (though we may eliminate
it in TLS 1.3)





> This is a distinct question from what RFC 7301 says, just a technical
>> statement
>> about what servers can and can't do. With that said, I read the statement
>> you
>> quote above (from the security considerations section) as saying that this
>> doesn't make the handshake less secure. I don't think it's inconsistent
>> with 7301
>> to condition cipher suites on the ALPN negotatiation.
>>
>
> Ok.   But I still think that 7301 does not give any guidance on how this
> can be done.
>
> The jetty team implemented ALPN directly from 7301 and nowhere in does it
> suggest that the extensions protocol selection may influence the cipher
> suites
> available or that the selected cipher suite may influence the selection of
> the protocol.
>
> The result is that we have developed a 7301 compliant extension that
> is incapable of implementing the protocol/cipher selection logic implied
> by h2-14 9.2.2.
>
> My preference is to not to make a relationship between the two concepts
> and that
> acceptable ciphers should be configured by server not by protocol.    But
> failing that,
> I definitely need guidance as to how to proceed. Select protocol then
> cipher?
> Select cipher then protocol?  Select both at same time?    I don't think
> it is acceptable
> to have the cipher/protocol selection to be an implementation detail.
>

Interesting point. Generally, the h2 ciphers were chosen so that they are
the
ones we wish you would prefer anyway, so if you were to do so, then this
would work.

-Ekr
Received on Friday, 5 September 2014 18:14:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC