Re: Discussion of 9.2.2

[Jason Greene <[e-mail]>]

On Sep 25, 2014, at 12:56 PM, Mark Nottingham <[e-mail]> wrote:

> Jason,
> 
> On 25 Sep 2014, at 6:20 pm, Jason Greene <[e-mail]> wrote:
>> 1. H2 stack X, running on System A hard codes all known H2 compliant 1.2 ciphers
>> 2. Time goes by, and a new stronger cipher C is released (either based on aero, or maybe just a new aead cipher in 1.3)
>> 3. System B is a high security site and only allows cipher C
> 
> which is not conformant with "implementations of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] with P256 [FIPS186].” (9.2.2) — assuming it’s still 1.2 (see below). You’re building a straw-man here...
> 
>> 4. The administrator on System A installs a TLS stack update to latest 1.3, which contains cipher C, so that A can talk to B
> 
> If both parties both speak 1.3, 9.2.2 doesn’t apply, as per recent discussion.

The problem is you do not know whether or not the peer is 1.3 until after negotiation, and cipher suite restrictions are specified in advance, and you can’t restrict to 1.3 only if you intend to support h1 usage (or 1.2 h2 clients) on the same port. The best you could probably do is retry the connection with a 1.3 restriction enabled and the cipher restrictions dropped, which defeats the lightweight establishment benefit of H2.

> 
>> 5. A now can’t talk to B, and the administrator can’t figure out why, and probably begrudges the switch to H2
> 
> See recent discussion regarding the language regarding unknown ciphers. Please address that proposal (mine or Martin’s).
> 

I was replying to Martin’s version. I was saying that the only way to meet that version of text is to either have a rich characteristics and priority API which isn’t prevalent today (see Michael Sweet’s most recent email), OR to hardcode the complete list (assuming the TLS stack allows a priority ordered list). 

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