Re: Stricter TLS Usage in HTTP/2

Hi,

On Thu, Jun 5, 2014 at 3:58 PM, Jason Greene <jason.greene@redhat.com> wrote:
>
> On Jun 5, 2014, at 8:01 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
>
>> We are abandoning NPN - an experimental extension used for nothing except negotiating SPDY, itself an experimental feature. Hopefully, but the time HTTP/2 is an RFC there will be a non-beta version of OpenSSL with ALPN. Regarding Java, I have no idea.
>
> I’m on the Java EE EG, and I can tell you that Java EE8 plans to add APIs targeting HTTP/2 and that puts a priority on Java SE8 (the current release) to support everything needed. In the meantime, implementors will just add it themselves. It’s not that complicated IMO.
>
> BTW I agree with the earlier comment that its a bad idea to go with NPN just because the libraries haven’t caught up. It might be slightly painful at first, but its far worse to have the spec tied to a non-ratified extension.
>
> Finally NPN is just as “inaccessible" as ALPN in Java ATM

For the record, there are implementations of both NPN and ALPN in
Java; they do require some special setup because there is no JDK API
to add TLS extensions, but they are there.
ALPN served by Jetty is already working live (using Chrome and SPDY).
I can give pointers if interested.

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

Received on Friday, 6 June 2014 06:18:30 UTC