TLS extensions API, ALPN and HTTP 2.0

[Michael McMahon]

Hi Simone,

I'm interested to understand why you think this Http 2 requirement
is difficult or impossible to implement in the JDK currently.

I thought, cipher suite selection would be independent of the ALPN 
mechanism.
So, a Http 2 client implementation would ensure that allowed ciphers
are in its list of proposed ciphers, and it's up to the server then to 
choose
an allowed one. And presumably, a server implementation can do the same?

- Michael.

On 17/09/14 11:02, Simone Bordet wrote:
> Hi,
>
> On Tue, Sep 2, 2014 at 11:11 AM, Vincent Ryan <vincent.x.ryan at oracle.com> wrote:
>> Your OCA is still being processed. When that has completed your name will be listed at:
>>    http://www.oracle.com/technetwork/community/oca-486395.html#b
>>
>> Until then, we can discuss these TLS/HTTP issues but we cannot include your APIs or source code.
> Just an update on this...
>
> While ALPN should offer mechanism independent from the protocol
> advertised or the cipher used in the TLS connection, it seems that the
> HTTP/2.0 spec has put some constraint that link the protocol
> advertised to the ciphers negotiated
> (http://tools.ietf.org/html/draft-ietf-httpbis-http2-14#section-9.2.2).
> Currently it seems that this HTTP/2 requirement is difficult, if not
> impossible, to implement in the JDK.
> I am following the HTTP/2 expert group to see if this issue is
> resolved, and working on the Jetty code to implement this feature.
>
> The idea being to wait a bit to define the ALPN APIs until this issue
> is resolved, to see if the resolution requires changes in the ALPN
> APIs.
>
> Thanks !
>