A fully fledged TLS Extensions API ?

[Simone Bordet]

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 !

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