TLS ALPN Proposal v4

[Simone Bordet]

Hi,

On Mon, Sep 7, 2015 at 5:54 AM, Bradford Wetmore
<bradford.wetmore at oracle.com> wrote:
> IMHO, the following works well.  I've added a new method that contains the
> ordered list of ciphersuites still to be tried which is a hint for ALPNinboked
> selection, but we delay the actual ciphersuite selection until after the
> ALPN value is chosen.  So the algorithm is now:
>
>     0.  Applications (especially server) might order suites with h2
>         first for TLSv1.2. sslParameters.setUseCipherSuitesOrder(true)
>         should be called on the server to ensure those suites are
>         tried first.
>
>     1.  Start Handshake.
>
>     2.  Internal server handshaker chooses the TLS version.
>
>     3.  The internal server handshaker finds the client/server/protocol
>         version intersection of the suites, loads the initial ordered
>         list into a new method on a SSLSession (obtained by the
>         getHandshakeSSLSession()), then iterates through the
>         ordered list of ciphersuites as usual.
>
>     4.  For each "candidate" ciphersuite, first call the
>         ApplicationProtocolSelector to choose an appropriate ALPN value.
>         The getHandshakeSSLSession() contains the negotiated TLS
>         protocol version and the ordered ciphersuite list with the
>         "candidate" suite as the first entry.
>
>         Note:  If the client sent unsupported ALPN values, the Selector
>         can throw a SSLHandshakeException at this point and generate the
>         "no_application_protocol" alert.
>inboked
>         The Selector can also either choose to ignore/skip the suite, or
>         accept the suite but choose no ALPN value.
>
>     5.  Continue the ciphersuite selection routine as usual (check for
>         appropriate Keys, etc).  The KeyManager now has access to the
>         negotiated TLS version and ALPN value along with theit
>         ciphersuite via the same/usual
>         getHandshakeSSLSession().
>         This satisfies the RFC 7301 goal of having
>         the certificate selection mechanism use the ALPN value.
>
>         As ciphersuites are removed from consideration via the
>         internal iterator in 3, they are also removed from the
>         corresponding SSLSession entry.
>
>     6.  When handshaking is complete, the applications should verify
>         that the session parameters (protocol version, ALPN value, and
>         ciphersuites, etc.) are suitable, and send a HTTP-level
>         INADEQUATE_SECURITY (H2) if there's a problem.
>
> In general, if the ciphersuites aren't ordered properly, that should be
> considered a configuration error on the part of the application(s). However,
> this dynamic ALPN selection approach still allows for appropriate ALPN
> values to be selected for each possible ciphersuite. That is, if the suites
> were ordered H1/H2, the ALPN value should be H1.
>
> For an example of such a selector, please see the new H2/H2+H1/H1
> ApplicationProtocolSelector implementions in
> ApplicationProtocolSelector.java, and how they are called in
> ServerHandshaker.java.
>
>
> Here is the latest:
>
> http://cr.openjdk.java.net/~wetmore/8051498/webrev.09

Are you sure this is the latest code ?
The relevant changes in ServerHandshaker are commented out.

I have the feeling that ApplicationProtocolSelector (APS) is not
really an application protocol selector, but a cipher suite selector.

APS seem to conflate cipher suite selection with application protocol
selection: the return value of select() actually is a 2-tuple that
means (ciphers[0], protocol) so that returning the empty string or
null does not have any effect on protocol selection, but only on
cipher selection.
You can for example implement APS without even looking at the
application protocol, just to exclude dynamically certain ciphers from
selection (e.g. based on performance or remote IP).

I don't understand exactly bullet 5 above. If APS chooses a cipher and
a protocol, but this is not a valid combination for the KeyManager to
select a certificate, what happens ? That APS is called again, right ?
But what if that was the last cipher ? Then APS won't be called again.
How can an application know that it is done trying to select a
protocol and that the protocol it chose is actually used ?

I guess this also brings to bullet 6: how can an application verify
that the N-tuple chosen is actually a correct one ? Is there an
additional callback that is being invoked (that applications can
implement) before the ServerHello is actually sent to the client ?

A very important point that I saw in the comments is support for TLS
session resumption - this has been asked multiple times by Jetty users
that were using Jetty's ALPN (and we implemented it).
Just make sure that whatever proposal enters JDK 9, session resumption
is supported.

My preference would go to the previous proposal (akin to Jetty - I
know I am biased) where protocol selection was happening in isolation
*after* cipher selection.
It is much simpler, and has the only drawback of not allowing
certificate selection based on application protocol (for which we
never had request from the community).

This proposal seems less clear to me, a bit of compromise between a
full fledged multi-selector API (it is in fact a 2-selector API for
cipher and application protocol) and the previous proposal (that was a
select-after-the-cipher selector API).

If the times are tight, I would go for the simpler approach and leave
the full fledged multi-selector API for JDK 10.

Thanks !

-- 
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.