TLS ALPN Proposal v5

[Jason Greene]

> On Sep 25, 2015, at 3:22 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> 
> On 09/25/2015 02:11 PM, Simone Bordet wrote:
>> Hi,
>> 
>> On Fri, Sep 25, 2015 at 7:23 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>>> The application protocol implementation chooses only valid cipher suites for
>>> the protocol.  Why would it choose one that is not valid, considering that
>>> the protocol implementation itself is the only thing that "knows" what is
>>> valid or not?
>> 
>> The cipher could fail for the number of reasons it fails in
>> trySetCipherSuite(), even if the application has chosen the right
>> combination of (application protocol, cipher, whatever else).
>> At that point you have to try another application protocol.
> 
> From my reading of that code, it can only fail if you specifically set up invalid combinations of cipher suite, protocol, and credentials.  The application code should have all the information it needs to set up a correct configuration though.

One example approach for a server-side H1 fallback scenario can be achieved using this approach, is to take the desired enabled portion of the supported cipher suite list for TLS 1.2+ (e.g. getSupportedCipherSuites, getSupportedSSLParameters, etc), which in simple scenarios is just the default suites (e.g. getDefaultSSLParameters, etc). Remove the H2 black-list from that and you have the h2 possible cipher-suite list. This list can then be further paired down based on key material (e.g disable ECDSA ciphers if only an RSA cert is present in the keystore). Finally the cipher list in client hello can be compared to find a possible intersection. If there is no intersection then use h1, otherwise configure h2.

One additional topic that I see came up on this list is the notion that cipher suite selection using ALPN is a temporary use-case, since H2 loses this problem with TLS 1.3. I think this viewpoint is too limiting. Fundamentally, the key use case that ALPN is achieving, is multiplexing two TLS ports over one. Any TLS policy that was required for a single protocol over a single port is likely to still be needed in a mixed protocol setup. Once you have non-overlapping policies then you need the ability to have logic which is distinguished by ALPN. We shouldn’t just look at H2 here, but think of it more generically.

Absent a non-limited TLS stack that does all the heavy lifting, deferring to the application is the next best thing. In some ways it can actually be better, since the portion of the logic on top of the JVM can evolve independently and more expediently than SE schedule allows. I also like David’s point that a simple solution is easier to backport to SE8, which is very important since EE8 is planned to require http2 and SE8 support.

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