Re: #612: 9.2.2 requirements

> On Oct 31, 2014, at 5:52 PM, Brian Smith <brian@briansmith.org> wrote:
>>> 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.
>> 
> The handshake does not precede ALPN selection. With ALPN, the ServerHello message contains the chosen protocol, and ServerHello is the first message the server sends. The TLS implementation cannot send even the initial bytes of the ServerHello message without knowing the chosen protocol because the length is encoded at the start of the message, and the length is dependent on the protocol chosen. If the TLS implementation provides a mechanism for the application layer to choose a cipher suite based on the protocol, then it needs to ask the application for the protocol before it chooses a cipher suite. Otherwise, like I said before, it should always just choose an 9.2.2-compliant cipher suite.

My point is that a legacy compatible client advertises cipher suites that aren’t compatible with H2 before H2 is selected. This is in contrast to a 1.3 client that would advertise 1.3 ciphers, and use SCSV fallback for pre 1.3 ciphers, which is a much more robust handshake, and leaves the TLS cipher selection where it belongs. 

I am not arguing that a TLS implementation could not provide an API that allowed selection of cipher suites based on ALPN selection. Thats just another variant of the nonexistant-api-with-no-known-plans-to-exist category.

>>> 
>>> > 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.
> 
> No, it doesn't have to reject XYZ. It can carry on based on the assumption that XYZ is OK. If it is, then the client will accept it. If it isn't, the client will return INSUFFICIENT_SECURITY to the server. (Keep in mind that this is only in the worse case where the server's HTTP/2 implementation is based on a TLS stack that is too inflexible to do better things.)

But that would violate 9.2.2 which clearly refers to both parties. I agree that it would be better if the language where changed to say that the client MUST and the server SHOULD, and would be in favor of that change. That would certainly address the interop issue, but it would still leave the possibility that an h2 client would exclude stronger ciphers than the TLS implementation supports, since the h2 stack may not yet be aware of them.


>>>  
>>> > 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.
> 
> Like I said above, if the server HTTP/2 implementation is in the unfortunate situation where it has no choice but to accept the cipher suite and protocol that the TLS implementation chose, and it has no way of learning the relevant properties of the unknown cipher suite XYZ, then it should assume that XYZ is valid as far as 9.2.2 is concerned and rely on the client to reject it, in the absence of better information.
> 
> However, again, this can only occur when the server software stack is designed in the worst possible way that could possibly work AND when the server software is configured poorly. Luckily, it is easy to change TLS stacks and HTTP stacks to use a better design, and it is possible (perhaps not so easy) to design things in a way that helps server administrators migrate to good cipher suite configurations.
> 

Sure, when and if everything is updated the issues go away. However the reality is the h2 spec is about to go final, and I don’t see everyone waiting around for this to all happen before they ship their implementations. What will happen is either implementations won’t bother to implement it, or they will try to make it work with what exists today, which is as you say “the worst possible way it could work”, and it will likely lead to interop issues. That is assuming 9.2.2 continues as is, with none of the possible fixes (including the server softening fix above). 

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

Received on Saturday, 1 November 2014 03:49:59 UTC