Issues with ALPN implementation in JDK 9

[Jason Greene]

> On Jun 14, 2016, at 2:52 PM, Simone Bordet <simone.bordet at gmail.com> wrote:
> 
> Hi,
> 
> On Tue, Jun 14, 2016 at 8:11 PM, Jason Greene <jason.greene at redhat.com> wrote:
>> If the case is that H3 blacks all RSA, then thats an easy test right? Just verify that keystore has an ECDSA key.
> 
> I don't think it is that easy.

Well certificate mechanisms aren’t introduced that often, so its probably good enough under such a scenario.

As a related tangent, it’s hard to imagine that RSA would get blacklisted unless quantum immune algorithms were rolling out, but that seems a long long long way away. 

> 
> The server logic has to mimic exactly what the JDK logic is, that is
> to verify the cipher and certificate compatibility.
> Not only, the server has to run the logic for SNI, the same logic that
> the JDK runs to get the right certificate. This logic would now run
> twice.
> 
> As I said, it is doable as long as the server logic duplicates and
> keeps in sync with the JDK logic so that it is guaranteed that the
> application protocol chosen by the server ends up with a cipher,
> chosen by the JDK, valid for that protocol.
> The moment the logic is different, there is a problem.

I think the issue is that to make the decision 100% perfect, you have to evaluate a number of factors together (ciphers, tls protocol, alpn protocol, key material, etc). The JDK TLS impl could certainly do it, but unfortunately, as you know, it was decided there wasn’t enough time to redesign the implementaiton in 9 to accommodate a multi factor negotiation incorporating alpn (the tuple approach). There’s also a secondary problem that new application protocols could be introduced before the JDK is aware of them, and with varying cipher requirements. So to make a tuple based JDK impl work, you would have to introduce a callback API with rich information for the application to use, and it would have to understand a lot about ciphers to use this. 

Ultimately we ended with a defer to application plan, which does allow for a perfect decision, but it does put a burden on the app for sure, but its not much more than what a callback approach like I mentioned above would require. 

If we let the JDK negotiate the cipher, and then the app negotiates the protocol separately, you can end up with wrong answers as well. For example, stick an h2 blacklisted cipher higher on the order list in ClientHello, and you can end up forcing h1 instead of h2, even if there is a perfectly valid h2 cipher present. 
> 
> Every time the JDK updates, you and me have to go and look inside the
> JDK to check whether the logic is changed, and if so, update our
> servers.
> And then we have to say that version X of our server only works with
> JDKs up to version Y, and that version X+1 of our server only works
> with JDK version Y+1.
> Been there, done that. I'd like to move to a better model that is future proof.
> I don't control which JDK people use to run Jetty.


I don’t see the challenge in supporting old JDK versions with the same up-to-date server code (at least after Java 9 where the app can control all of this)? 


> 
> I would rather not duplicate all the JDK logic into an application.

Well I think the “lazy” approach I described before would work quite well with very few application updates necessary, basically zero today, and another whenever a new HTTP/X version rolls out, but you have to do that anyway. With a more thorough application stack though its possible to make perfect decisions on these sorts of things. 

I can appreciate the desire not to duplicate the JDK; it would be nice to see a richer tuple based impl in the future. 

> 
> Thanks !
>