JEP 244: TLS Application-Layer Protocol Negotiation Extension

Bradford Wetmore bradford.wetmore at
Wed May 20 00:30:02 UTC 2015

Hi Simone/Thomas/David/others,

Thomas wrote:
> would it not be an great idea to combine all these new extensions to
> an generic way how to handle the SSL Protocol Handshake ?

I've finally been able to deep dive back into ALPN, specifically looking 
at the ideas of a general Hello extension framework, but also a more 
general handshaking framework that could support additional/future 
handshake message types (e.g. 

After reading lots of current/proposed/private TLS extension RFCs[1][4], 
I concur with much of what Xuelei wrote previously (see below).  I also 
agree that having a Hello+extension explorer/modifier would have some 
utility for ALPN and a few others (including TLS_FALLBACK_SCSV), but 
many of the current extensions require modifications to the 
protocol/calculations and/or the KeyManager/TrustManagers and thus can't 
simply be bolted into SunJSSE using the current APIs/implementations. In 
most cases, it requires modification of the underlying SunJSSE 
implementation to support them, or else a strong working knowledge of 
the TLS protocol to make the right insertions in the right place.

I have varying degrees of familiarity with these extensions, so I may 
have missed an obvious way to implement something and am certainly open 
to suggestions, but here's the current extension list and my notes:

#     Extension Name                         Reference
=     ==============                         =========
0     server_name                            [RFC6066]
Currently supported

1     max_fragment_length                    [RFC6066]
No: Protocol I/O modifications needed to generate proper sized packets.

2     client_certificate_url                 [RFC6066]
No: Requires new KM/TM API style that knows how to fetch URLs

3     trusted_ca_keys                        [RFC6066]
Yes: pretty straightforward

4     truncated_hmac                         [RFC6066]
No: Protocol modifications needed

5     status_request                         [RFC6066]
Currently under development for JDK 9[2]

6     user_mapping                           [RFC4681]
Possible: need to insert Supplemental Data handshake message type into 
right place in handshake, but probably not too difficult.

7     client_authz                           [RFC5878]
8     server_authz                           [RFC5878]
Possible: also must insert Supplemental Data into the right places in 
handshake, but probably not too difficult.

9     cert_type                              [RFC6091]
No: Currently only support X509KM/X509TM, not OpenPGP credentials.

10    elliptic_curves                        [RFC4492]
11    ec_point_formats                       [RFC4492]
Currently supported

12    srp                                    [RFC5054]
No: Requires new ciphersuites and ClientKeyExchange format support.

13    signature_algorithms                   [RFC5246]
Currently supported

14    use_srtp                               [RFC5764]
No: APIs do not expose the PRF and TLS master secret mechanisms.  Might 
be able to talk RTP using socket overlays, but the other issues make 
this impossible.

15    heartbeat                              [RFC6520]
No: Don't support heartbeat message type.

16    application_layer_protocol_negotiation [RFC7301]
Currently under development for JDK 9[3]

17    status_request_v2                      [RFC6961]
Currently under development for JDK 9[2]

18    signed_certificate_timestamp           [RFC6962]
No: We might be able to support this extension, but it would be 
incomplete as OCSP doesn't support  Clients 
must support X509v3 cert extension, TLS exension, and OCSP:  servers 
only need to support one.

19    client_certificate_type                [RFC7250]
20    server_certificate_type                [RFC7250]
No: We do support X509 certs, but we don't support Raw Public Keys with 
our current impl so this would not be a complete implementation.

21    padding                                [draft-ietf-tls-padding]
Yes: but would require educated guesses on how much padding to add.

22    encrypt_then_mac                       [RFC7366]
No: protocol modifications needed

23    extended_master_secret                 [draft-ietf-tls-session-hash]
No: would require changes to the PRF computation parameters.

35    SessionTicket TLS                      [RFC4507]
Possible: requires new SessionTicket message be sent in the right place, 
probably not too difficult.

13172 NPN                                    [4]
Possible: requires insertion of a NextProtocol message between CCS and 

65281 renegotiation_info                     [RFC5746]
Currently supported

I also looked at extending the handshake examiner for channel bindings 
using either raw TLS X509Certs or Finished messages.  It seems easier to 
me if developers had 2-4 methods with descriptive names rather than 
having to use a generic handshake message examiner/modifier and an 
intimate working knowledge of the TLS protocol.

At this point, my feeling is to provide a default ALPN selector (using 
the server-ordered list), but also have a Hello Callback+Examiner with 
the ability to add/modify/delete extensions upon receipt/before 
transmission, including handling unknown/future extensions 
(getEncoded()).  It will be up to the application to parse/handle said 
extensions.  That would help guide HTTP-2 protocol/ciphersuite/ALPN 
selection (i.e. fallback to HTTP/1.1 if not TLSv1.2), plus the 
TLS_FALLBACK_SCSV (however, Florian's work might be in place soon), but 
I'm not sure how much additional use it will be.  Initially I would 
probably expose via API only the supported extensions, along with an API 
for determining if an "unknown" extension is supported by the underlying 
implementation (SSLSocket/SSLEngine.isExtensionSupported()?).

One last comment, the IETF released RFC 7540 (HTTP/2) last Friday. 
There are a few tweaks that we will need to make regarding keysizes, 
ciphersuites, and TLS renegotiation.  We'll be filing bugs on those shortly.




JEP 249: OCSP Stapling for TLS

JEP 244: TLS Application-Layer Protocol Negotiation Extension


On 4/13/2015 8:02 PM, Xuelei Fan wrote:
> 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:
>> 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
>> 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> 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:
>>> (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.

More information about the security-dev mailing list