TLS ALPN Proposal v2

[Simone Bordet]

Hi,

On Wed, Jun 3, 2015 at 2:56 AM, Bradford Wetmore
<bradford.wetmore at oracle.com> wrote:
> Hi,
>
> I have just posted the second iteration of the ALPN proposal which hopefully
> addresses all of the comments raised here.  It is in javadoc format, but
> things can certainly be adjusted:
>
>     http://cr.openjdk.java.net/~wetmore/8051498/webrev.00/
>
> Please see the archive [1] for previous design discussion.  I will be
> writing up usage examples in the next few days.
>
> The significant changes:
>
> ExtendedSSLSession
>     public List<String> getReceivedApplicationProtocols() {
>
>     This will allow applications to examine which protocol names were
>     sent.

This is a constant once the application protocols are received, so it
can be surely retrieved from SSLParameters.
I don't understand why it is replicated here ?

> SSLParameters
>     mentions both ALPN/NPN as possible protocols.  I removed the
>     discussion about "server" and "client" since ALPN/NPN essentially
>     reverse the roles.
>
>     mentions "appropriate character sets" for String-byte[] conversions
>     such as UTF-8 for ALPN.
>
>     The application protocol selector is now a @FunctionalInterface
>     (i.e. lambda-ready) called SSLFunction.  It is to throw an
>     SSLException if no values are supported, or null if you want to
>     treat as an unknown extension.
>
>     Defined constants for HTTP/1.1 and HTTP/2.
>
> SSLSession
>
>     Called out that getHandshakeSession's ciphersuite may vary until
>     selected.
>
> SSLBase
>
>     A new marker interface that SSLEngine/SSLSocket will implement.
>     This will allow for a single SSLFunction instead of having
>     SSLFunctionSSLEngine and SSLFunctionSSLSocket.  It does require
>     that the lambda do a instanceof, unless we were to move the common
>     Socket/Engine APIs into this class.

I'm not sure about this one being a marker interface.
I could understand if it extracted the common functionality of
SSLEngine and SSLSocket, but a marker interface does not really add
much, and perhaps I would prefer it entirely gone.

On the same note, why is SSLFunction generic at all ?

Also, it is critical to detail how the mechanism work.
Will SSLFunction be invoked multiple times, or only once ? When,
exactly, with respect to cipher selection and alias selection ?

Example implementations for SSLFunction would be great to have: the
typical HTTP/2 case is to select the application protocol based on the
TLS protocol and the already negotiated cipher.

Thanks !

-- 
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz