A fully fledged TLS Extensions API ?

[Simone Bordet]

Hi,

On Mon, Nov 10, 2014 at 10:36 PM, Bernd Eckenfels
<ecki at zusammenkunft.net> 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).

Well, JEP 110 (http://openjdk.java.net/jeps/110) is about a HTTP
client that supports h2.
I think it's not too far-fetched to expect jfx/swing widgets, JAX-RS
clients, etc. to support h2 in a close future, so I would not rule out
h2 support for clients.
ALPN would be a prerequisite for h2, since unlikely servers will
implement h2 in the clear.

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

For example for the NPN extension to work, it requires collaboration
with the TLS implementation to send a new TLS message at the right
moment.
A JDK 9 client application would be able to add the NPN extension via
the API, but then the JDK would not be able to send the new message at
the right time because NPN won't be implemented in JDK 9.

There are several ways to handle these cases, but I agree that they
may expose an overspecification of the API similar to that of the
collections API: throw UnsupportedOperationException if you can't
handle it (e.g. Iterator.remove()).
Whether there is more advantage for applications to have the API and
risk an UOE, or not having the API and be stuck, I don't know (and
it's the reason for this email, to discuss it :)

A declaration of the impact of an extension on the TLS protocol, akin
to Spliterator.characteristics() may help. Some extensions have no
impact and may be freely added, others require the TLS implementation
cooperation.
A couple more callbacks for [Client|Server]Hello received, for
applications to interact with the extensions for SSLSocket (similar to
HandshakeCompletedListener) would be needed too.

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