A fully fledged TLS Extensions API ?

[David M. Lloyd]

Another area of applicability is inner authentication mechanisms which 
make use of channel binding; these mechanisms need to actually acquire 
chunks of data from the handshake exchange.

http://tools.ietf.org/html/rfc5929 for more info

On 11/10/2014 03:36 PM, Bernd Eckenfels wrote:
> Hello,
>
> the question is, what is a extension API actually helping with: the JSSE
> implementation is slow to adopt to typical advances in TLS browser
> "wars". While this is not so bad as nobody implements a Web Browser in
> Java anyway, it does make it harder for server vendors to offer a full
> stack (without native libraries or reverse proxies).
>
> Having an API to handle extensions could help with this a bit, however
> a lot of the extensions cannot be bolted on, they alter the handshake
> sequence, introduce new messages or alter interpretatrion of existing
> enums. So while ALPN can be handled pretty easily, it would be harder
> for things like eliptic_curves or supported_signatures or SRP (or Poly
> authenticator) - or TLS_FALLBACK_SCSV (or simple things like rate
> limiting the renegotiations).
>
> The other question is, if advances in SSL/TLS protocol really need to
> be bound with major java versions. It would do the world a favor to
> have a backport of a system property allowing TLS1.2 to be used by
> default. Having the JSSE implementation beeing its own sub project
> under the openjdk could help with that. Especially if providers become
> more plugable. And optimizations like intrinsic are not bound to the
> providers, but to the actual primitive needed (like AES GCM).
>
> Gruss
> Bernd
>
> Am Mon, 10 Nov 2014 14:28:44 +0100
> schrieb Simone Bordet <simone.bordet at gmail.com>:
>
>> Hi,
>>
>> On Mon, Nov 10, 2014 at 2:07 PM, Florian Weimer <fweimer at redhat.com>
>> wrote:
>>> On 11/07/2014 02:06 PM, Simone Bordet wrote:
>>>
>>>> This email is about the idea to introduce in JDK 9 a fully fledged
>>>> TLS Extensions API.
>>>>
>>>> Adding ALPN [0] support to JDK 9 requires, differently from other
>>>> TLS extensions, to provide application code that will be run in the
>>>> context of the TLS implementation, rather than just values such as
>>>> booleans or strings.
>>>
>>>
>>> That's going to be interesting if you need to support non-blocking
>>> operation for use with SSLEngine.
>>
>> In the case where you have to load the configuration from a place
>> where it may take a lot of time, you can easily change the ALPN API to
>> something like:
>>
>> For the client:
>> void selected(String protocol, CompletableFuture<Void> callback)
>>
>> For the server:
>> void select(List<String> protocols, CompletableFuture<String>
>> callback)
>>
>> and when you're done call callback.complete() or
>> callback.completeExceptionally().
>>
>> This would mean that the TLS implementation has to wait for those
>> callbacks to be completed before proceeding.
>>
>> On one side, having application code to complete the callbacks is, in
>> our experience, error prone (i.e. applications forget it)
>> On the other side, applications that make use of this API are
>> typically on the implementer side rather than on the developer side
>> (here I mean people that implement a server, rather than a developer
>> of a webapp), so I guess a callback, albeit more complex, may give
>> implementers more room for different implementations.
>>
>>>> IMHO this chance can be lifted to provide a full TLS Extensions
>>>> API.
>>>
>>> I don't think this is possible because TLS extensions can alter the
>>> TLS handshake, result in additional messages being exchanged, and
>>> generally alter the protocol in unforeseeable ways.  On top of
>>> that, the concrete TLS implementation is not fixed, it can be
>>> swapped out, so tying the extension API to the existing OpenJDK
>>> internals will not work for everyone.
>>
>> Can you expand what you mean here ?
>> If a TLS extensions API is provided by JDK 9, would it not be
>> implemented by providers like they do with the other APIs they have to
>> implement to be a compliant provider ?
>> It's a little more effort for providers, but with a public API should
>> be implementable by any provider and an application would be portable
>> across providers.
>>
>> Thanks !
>>
>

-- 
- DML