Re: 9.2.2, Rough Consensus, and Working Code

> On Nov 6, 2014, at 1:52 AM, Greg Wilkins <gregw@intalio.com> wrote:
> 
> 
> On 6 November 2014 16:26, Jason Greene <jason.greene@redhat.com> wrote:
> >
> >
> > Hi Greg, can you take a look at the small proposal I sent a few days ago. I think its closer to what you are looking for:
> > https://github.com/http2/http2-spec/pull/639/files
> 
> 
> Jason,
> 
> your proposal says:
> 
> + latency imposed by using a separate connection for fallback. Prohibited cipher suites
> + MUST be advertised at a lower preference than permitted cipher suites.
> 
> I don't think ordering helps as there may be no ciphers in intersection of client/server h2 acceptable cipher sets (as was the case when I ran jetty on java 7).    Without a robust handshake, it is impossible for a server to know at what point in the list of offered ciphers the weak fallback ciphers begin.   Many servers will never even see the list and will just see the negotiated cipher.

Assuming the ordering aspect was actually implementable, which it seems not, the reasoning for ordering on the client is just to ensure that when a server accepts an unknown cipher it is actually not a prohibited one. Since the TLS spec requires that the preference list be followed, and since the client is also required to provide at lest TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, there will always be at least one intersection (when both ends are compliant).

Although are you talking about the handling of non-compliant clients, and that they should have a more graceful fallback?

> 
> 
> + </t> 
> + <t>
> + Servers MAY allow unknown ciphers that are negotiated by a TLS 1.2 implementation.
> + This prevents potential interoperability issues involving future ciphers supported
> + by the underlying TLS 1.2 implementation, but are not yet understood by the server.
> + Due to the restrictions on clients above, prohibited cipher suites are still
> + prevented from use with HTTP/2.
> 
> If the server allows an unknown cipher for h2, and the client rejects it with inadequate security, then the connection will have failed - EVEN if there are acceptable ciphers if h1 was chosen.

This was basically why the order element was there, but it’s true that if you have a non-compliant client that offers the h2 alpn without ciphers it fails when h1 would have worked. 

> 
> Also note that a server might not get to choose h1 over h2 as the ALPN may be offloaded with TLS.

Sure but if its offloaded, wouldn’t the offloading use either:

a) h2c 

or

b) independent SSL stream which either drops the ALPN, or also negotiates according to the spec

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

Received on Thursday, 6 November 2014 19:31:41 UTC