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

On 5 September 2014 15:45, Eric Rescorla <> 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
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.

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


Greg Wilkins <> HTTP, SPDY, Websocket server and client that scales  advice and support for jetty and cometd.

Received on Friday, 5 September 2014 06:47:03 UTC