TLS ALPN Proposal v5

[David M. Lloyd]

Here are some solid reasons that this is the best possible approach:

* It will work for 100% of foreseeable use cases - i.e. there is 0% risk 
of permanently baking in flawed logic into the API
* It is dead simple - only one new method on SSLSocket/SSLEngine to set 
the protocol list (client) or selected single protocol (server)
* Because it is dead simple, it should be very easy to backport to Java 8
    *Example 1*: Add a static 
org.openjdk.jsse.ALPN#setApplicationProtocol(SSLEngine | SSLSocket s, 
String[] protocols) method, which calls (maybe even reflectively?) the 
setApplicationProtocol() method on the SSLEngine/SSLSocket 
implementation if it is present & public
    *Example 2*: Add an org.openjdk.jsse.ALPNAware interface with the 
setApplicationProtocol(String[]) method, which is implemented by JSSE 
providers
* Now Java EE 8 can trivially achieve HTTP/2.0 support with very low 
risk to either the JDK/SE timeline or the EE timeline
* Since most or all of the "hard" logic is on the server side, the 
majority of API consumers will have an easy time using the API
* We server developers can handle the rest!

On 09/25/2015 12:23 PM, David M. Lloyd wrote:
> On 09/25/2015 12:13 PM, Simone Bordet wrote:
>> Hi,
>>
>> On Fri, Sep 25, 2015 at 6:49 PM, David M. Lloyd
>> <david.lloyd at redhat.com> wrote:
>>> A: receive raw SSL packet on Socket or SocketChannel
>>> A: examine SSL ClientHello, extract SNI, ALPN, cipher suite info
>>
>> This requires the application to write a TLS parser. This is currently
>> not necessary, nor provided.
>
> It is already necessary to make many non-trivial SNI decisions.  I don't
> see ALPN as deserving higher treatment than SNI.
>
>> You think this could be provided via a JDK utility class ?
>> And if so, how can it be extended in the future when more TLS
>> Extensions are defined ?
>
> I don't think it's necessary, no.
>
>>
>>> A: use whatever algorithm(s) you want to analyze SNI/ALPN/cipher
>>> suite info
>>
>> The application must intersect the ciphers, application protocols...
>> perhaps again this can be done by some JDK utility class.
>
> The point of the approach is that it is unlikely that any JDK-driven
> logic will be adequate for all use cases.  It's better to let the
> application be a black box: ALPN+SNI+Ciphers -> app logic -> one ALPN
> protocol, one SNI name, only valid ciphers.
>
>>> A: either proxy the connection, or obtain or create the relevant
>>> SSLContext
>>> from the desired provider
>>> A: construct server-side SSLSocket/SSLEngine from SSLContext
>>> A: setApplicationProtocol(H2)
>>> A: setEnabledCipherSuites(only allowed suites in desired order)
>>> A: start handshake
>>> J: receive ClientHello (buffered from A)
>>> J: verify SNI is matched, fail otherwise (as today)
>>> J: verify ALPN is matched, fail otherwise (new)
>>
>> There is a missing step here which is to verify the cipher
>> (trySetCipherSuite() logic).
>
> 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?
>
>> If that fails then we must try another application protocol.
>> We cannot just fail the connection.
>> How do we go from here to the top again to choose another protocol ?
>>
>>> J: send ServerHello (with the single, user-selected protocol)
>>> ...
>>>
>>> This is very simple from the JDK perspective, and also much more
>>> flexible.
>>
>> Well, I kinda like it, but I have strong reservations that it cannot
>> really "negotiate" the application protocol, meaning that if one
>> application protocol fails, try the next, and then the next and so
>> forth until one succeeds (or they all fail).
>
> This validation should have happened before the JDK ever has a chance to
> be involved.

-- 
- DML