JEP Review Request: TLS Application-Layer Protocol Negotiation Extension

[Simone Bordet]

Hi,

On Mon, Feb 2, 2015 at 8:27 PM, Bradford Wetmore
<bradford.wetmore at oracle.com> wrote:
> The draft JEP “TLS Application-Layer Protocol Negotiation Extension” is now
> available for community review:
>
>    https://bugs.openjdk.java.net/browse/JDK-8051498
>
> This JEP is to add support for the Application Layer Protocol Negotiation
> (ALPN) TLS Hello extension [1] in JSSE. ALPN provides a mechanism for
> declaring the application protocols that are supported over a TLS
> connection.
>
> We need this functionality to make JDK 9, so this JEP needs to get into the
> JEP pipeline soon.  Community review is a precursor in the process before it
> can move to "Submitted."
>
> For now, there is a simple API proposed (similar to JDK 8 SNI), but I'm
> parsing the discussions that took place on security-dev in August[2],
> September[3], and November 2014[4], and the current API is likely not
> flexible enough.

I have taken a quick look at the proposed API as reported here:
https://bugs.openjdk.java.net/browse/JDK-8062848.

I don't think it is enough, since what needs to be provided by the API
is the ability to run application code.
That is the API must be something like:

sslParameters.setALPNSelector(protocols -> protocols.get(0));

That is, it should take a lambda of the form:

public String select(List<String> protocols);

Also, the lambda would be different for clients and servers.

See my November message for further details:
http://mail.openjdk.java.net/pipermail/security-dev/2014-November/011399.html

Somehow orthogonal to this, the HTTP2 working group has finally
stabilized the requirements for negotiating HTTP2.
For a server that receives a list of ALPN protocols, and that wants to
negotiate "h2", it has not only check that both itself and the client
support the "h2" protocol, but also that the cipher requirements for
HTTP2 are satisfied.
Note that this requirement only exist for negotiating HTTP2.

While I agree that the major use case for ALPN is HTTP2, ALPN is
nevertheless a generic mechanism to negotiate the application protocol
over TLS, so the HTTP2 cipher selection should not be "hardcoded".
So perhaps the JDK should also provide a utility class, say
HTTP2ALPNServerSelector, which implements the before mentioned lambda
adding the specific HTTP2 cipher logic, although this may be out of
scope for this ALPN work.
I mentioned it as a reminder that the API cannot be too "closed", as
the protocol selection may need to access contextual information such
as the TSL protocol version, the negotiated cipher, possibly the
server name indication, etc.

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