Re: #612: 9.2.2 requirements

> On Nov 5, 2014, at 6:08 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 
> 
>> On 6 Nov 2014, at 10:56 am, Jason T. Greene <jason.greene@redhat.com> wrote:
>> 
>> 
>>> On Nov 5, 2014, at 5:22 PM, Mark Nottingham <mnot@mnot.net> wrote:
>>> 
>>> However, it still hasn't been shown how this will be the case with HTTP/2, if both the client and server are conformant to the proposed text.
>> 
>> Why do you keep saying this? I have reposted the frequently discussed problematic scenario numerous times in response to it.
>> 
>> I'm also not saying it can't be fixed. I even have a candidate PR for one option that came out of a discussion with Brian (who at least acknowledged the issue). Other options and proposals have been brought up (as recently as today). I have summarized them on multiple occasions.
> 
> See: <http://www.w3.org/mid/6F1A838B-0BC8-4D6D-856E-414DFBF747AF@mnot.net>
> 
> You yourself said earlier:
> 
>> Reconsidering Brian's argument regarding ALPN behavior, it's perfectly plausible that a TLS impl could validate the ALPN + cipher combination and ensure either the right ciphers are chosen, or that the ALPN missing the proper cipher requirements is not selected by the application. Following this line of thought I must concede that there is no TLS protocol problem. 
>> 
>> In fairness, the issue instead a practical one (the lack of support by TLS implementations, and the inability of H2 implementations to comply with these rules at the time of H2 standardization)

Yes, but these statements are not exclusive. TLS + ALPN can theoretically be implemented in an interoperable way with mixed cipher suite requirements. However, in practice the H2 implementation is at the mercy of the TLS implementation it uses. Both parties can enforce their respective portion of 9.2.2 in total compliance, yet the end result will be a failed negotiation. 

Again the issue is that all the H2 stack is in a position to do, is to validate what the TLS stack already did, which is too late. If TLS and H2 have different knowledge, which again is likely since common practice is for a shared dynamically linked TLS library, then the H2 stack can find itself being overly restrictive because thats what the 9.2.2 text requires it to do. All it takes is for the TLS stack to support a newer cipher than the H2 stack recognizes.

All we need to do to fix it is to slightly soften the restrictions on the server side. so that the H2 stack has the option to accept the stronger cipher it doesn’t yet know about. This allows the TLS implementations of today to work, as well as the theoretical future implementers that 9.2.2 was created for.

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

Received on Thursday, 6 November 2014 01:39:44 UTC