JEP 244: TLS Application-Layer Protocol Negotiation Extension

[Xuelei Fan]

Thanks for the proposal.

A general TLS/DTLS extension API and pluginable extension implementation
is a good idea.  But as there is no rules about how an extension may
impact the handshake flow, it is not easy to define a general APIs for
all existing known or unknown extensions and future extensions.  For
example, an extension may impact the cipher suite selection, may need to
define new handshake messages, may need new algorithm implementation,
may impact the algorithm used to sign handshake messages, may impact the
algorithm used to protected application data, etc.  An extension may
impact every details of handshaking, not only the client hello and
server hello messages.  It would be great if there are general APIs that
are simple and cover the possible impact in every details of
handshaking.  I'm open for more advices.

Maybe we can have APIs to define the extension parameters, rather than
the handshake implementation.  But as we already have SSLParameters, I
don't think we need extra APIs for extension parameters any more.

JSSE is open source and an provider based framework.  Alternatively,
we'd like to accept extension implementation contributions, or developer
can define their own private provider if necessary.

Regards,
Xuelei

On 4/14/2015 1:14 AM, Thomas Lußnig wrote:
> Hi,
> 
> this could be an interface for such an Callback.
> It allow hello extensions as well as handshake extensions.
> If it would be really clean we would have an handler for:
> - NPN
> - ALPN
> - Channel ID
> - ZertificateSignature
> - OCSP-Stapling
> - ServerName
> - Session Ticket
> 
> The handler could be also used for handling:
> - TLS_FALLBACK_SCSV
> 
> The current way is that all these extensions are in the sun Private
> package space
> and to make it even worse each extension is written in another way.
> Also i am missing an API defined way to extend the list in
> sun.security.ssl.CipherSuite.
> 
> Gruß Thomas
> 
> public interface HelloHandler {
>     /** 
>       * Allow to add extesions to Server/Client Hello 
>       * based on the Client/Server hello */
>     public void handleHelloMessage(ClientHello clientHello, ServerHello serverHello);
>     /** Allow to add new Handshake Messages based on 
>       * the Client/Server Hello 
>       */
>     public void sendHandshakeMessage(HandshakeOutStream handshakeOutStream, ClientHello clientHello, ServerHello serverHello);
>     /** 
>       * define an order of the extensions 
>       */
>    Class<? extends HelloHandler > runBefore();
>     /** 
>       * define an order of the extensions 
>       */
>    Class<? extends HelloHandler > runAfter();
> }
> 
> 
> 
>> Hi,
>>
>> On Mon, Apr 13, 2015 at 6:22 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>>> Do you know of a Java TLS implementation that has APIs like this already?  I
>>> am also interested in this for the ability to implement authentication
>>> mechanisms (GSSAPI and SASL) that rely on channel binding, so I would like
>>> to see such an API materialize as well.
>> I posted a while back such APIs from 3rd party JSSE implementations:
>> http://mail.openjdk.java.net/pipermail/security-dev/2014-August/011014.html
>> (at the end).
>>
>> The problem that has been raised is that if you offer a generic TLS
>> extensions API, then the extension may have a semantic that it's not
>> implemented.
>>
>> Imagine this TLS extensions API already existed, to add extensions to SSLEngine.
>> Now, ALPN comes along as a new TLS extension. An application could
>> create their own ALPNExtension subclass (extending a standard one
>> provided by the TLS extensions API), and add it to the ClientHello.
>> But there is no code in the JDK that calls the application, asking (on
>> the server) to select one of the protocols, for then send back the
>> chosen protocol to the client.
>> This could be solved by a callback API at the moment the ClientHello
>> is received by the server (and the ServerHello by the client), so the
>> application can examine the ALPN protocols.
>>
>> The NPN extension was doing something even more complicated, creating
>> an additional TLS message that needed to be sent at the right time.
>>
>> It may be that a TLS extensions API (to add/remove/query TLS
>> extensions) *and* a callback API to analyze "hello" messages when they
>> are received is enough to cover a lot of cases, perhaps even all
>> currently existing ones.
>>
>> I asked for feedback some time ago about the status of the ALPN
>> implementation; would be great if the security team could update the
>> current status.
>>
>