A fully fledged TLS Extensions API ?

[David M. Lloyd]

On 11/10/2014 07:28 AM, Simone Bordet wrote:
> 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().

Note that SSLEngine already has an opaque "runnable tasks" mechanism 
that non-blocking implementations have to deal with.  Implementations 
already cannot assume that these tasks do not block, so any blocking 
work can just be wrapped in one of these.

Not that I'm specifically endorsing this idea (or not); I just wanted to 
clarify that fact.

-- 
- DML