Re: Discussion of 9.2.2

On Sep 25, 2014, at 3:30 AM, Martin Thomson <martin.thomson@gmail.com> wrote:

> Based on this discussion, I think that there needs to be a d) here
> where we note that implementations MUST NOT offer cipher suites where
> these properties (PFS, stream/block mode) are unknown.  This was an
> assumption on my part that turns out to be important.  With that
> change, I think that the concern about fragility becomes immaterial.

That doesn’t really solve the problem. If you are implementing an H2 stack where the TLS stack it is used with does not provide the rich APIs I described in my previous email, then the only way to meet this requirement is for the H2 stack to specify a whitelist of all ciphers (as doing that suggests it is aware of the properties). Once it white-lists future ciphers used by peers that meet the AEAD (or greater) test will fail.

To use an example:

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
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
5. A now can’t talk to B, and the administrator can’t figure out why, and probably begrudges the switch to H2

On the other hand, if stack X had simply ignored 9.2.2, it all would have worked out fine. 

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

Received on Thursday, 25 September 2014 17:20:38 UTC