Re: #612: 9.2.2 requirements

> On Oct 31, 2014, at 4:05 PM, Brian Smith <brian@briansmith.org> wrote:
> 
> Jason Greene <jason.greene@redhat.com> wrote:
> > The question at hand is what interoperability cost is involved in 9.2.2. If it is a cost paid by a few implementations who don’t have adequate APIs immediately at hand, that is emphatically *not* a technical issue.
> 
> AFAIK there is exactly *one* TLS implementation out there that has nearly adequate facilities, NSS.
> 
> If NSS's facilities are adequate, then that is a very good sign for other implementations, because NSS's facilities for this are very simple, were very simple to implement, and were deployed without any (AFAIK) disruption to any production systems.

It’s close, but I think its still missing the ability to actually influence the handshake, which would require characteristic based priority ordering (or alternatively large white lists that hopefully match). Hey if its easy for all of them to address this problem, thats great, but IMO we should be asking them, not just assuming it will occur. 

>  
> 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
> 
> He wrote, in part:
> 
> > 4) Server TLS stack picks ALPN "h2" and ciphersuite
> >     XYZ (must be 9.2.2 compliant because of 1).
> > 5) The HTTP/2 stack has no (or only partial[1]) idea what XYZ is.
> 
> First of all, it is almost always going to be a bad idea to have the server TLS stack choose which application protocol to use.
> Instead, it should defer that choice to the server application.

That doesn’t help because the problem is the cipher selection happens independently of all of that (handshake precedes the ALPN selection), and its shared between H2 and H1 support thats the issue.

> Second of all, if the server doesn't take that advice, and the TLS stack has already chosen h2, then the HTTP/2 layer might as well keep going on the assumption that XYZ is OK, because it hasn't given itself any better choice, due to not taking that advice. I

Since it does not know that XYZ is allowed by 9.2.2 it has no choice but to reject. Without a proper protocol negotiation the H2 implementation is required to either have in-synch consistency with the TLS stack (and also consistency with the peer TLS & H2 stack), or it needs the ability to ask and influence the TLS stack as part of the TLS stacks handshake, using some simpler set of rules.

> f things don't work, the server administrator will likely fix it by improving the cipher suite configuration, probably by reading section 9.2.2 of the specification or documentation derived from it. Of course, it's better for the server software implementation to just automatically do the right thing,

Yes the best course of action will be for the administrator to add XYZ in the configuration. However, if a server implementer simply ignored 9.2.2, XYZ would have succeeded, without user intervention, leading to better security and performance. Until the proper TLS APIs exist (I’m not holding my breath), or TLS 1.3 occurs, this is the best action an implementer can take.

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

Received on Friday, 31 October 2014 22:21:36 UTC