JEP 244: TLS Application-Layer Protocol Negotiation Extension

[Thomas Lußnig]

Hi,

the point is simple. The description for the code say that TLSv1.2
should not have an valid PRF.
But for example SSL_DH_anon_WITH_DES_CBC_SHA which is obsoleted in TLSv1.2.
But since obsoleted is set to TLSv1.2 the code part:

if (obsoleted < ProtocolVersion.TLS12.v) { prf = P_NONE; }

Does not set the PRF to the invalid NONE as i would expected with the
description.

Gruß Thomas

> 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.
>>>