Re: #612: 9.2.2 requirements

> On Oct 31, 2014, at 4:14 PM, Patrick McManus <mcmanus@ducksong.com> wrote:
> 
> 
> On Fri, Oct 31, 2014 at 3:42 PM, Jason Greene <jason.greene@redhat.com> wrote:
> 
> Ilari’s use case is a great example of where it all goes wrong:
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0167.html
> 
> I believe that just describes an API limitation, not a protocol problem. A hypothetical implementation directly participated in the negotiation of XYZ and h2 but for whatever reason cannot ensure the relevant properties of XYZ with respect to h2's application profile of tls laid out in 9.2.

It’s fundamentally a protocol issue, and the API requirements are, in fact, created to work around this protocol problem. Both ends of the TLS connection have a vested interest in supporting legacy ciphers on legacy protocols, and so it will be common that clients will offer ciphers they do not support with H2, and servers will accept ciphers that are not supported with H2, since both H1 and H2 share the same underlying TCP port.

In order to fix the protocol problem you need a way to associate the cipher suites with the application protocol. The only facility in the TLS handshake, as it defined today, that can accomplish that, is the TLS protocol version. If H2 required TLS 1.3, these problems would not occur. 

The requirements in 9.2.2 try to achieve similar behavior to the more accurate TLS 1.3 restriction, by mandating that H2 stacks needlessly duplicate TLS rules after cipher selection has already been made, thus leading to possible errors. Further even if the H2 stack gets it right, it’s common industry practice to update TLS libraries independent of the H2 stack leading to the H2 stack having older inaccurate rules (version-skew).
  
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

Received on Friday, 31 October 2014 21:53:49 UTC