TLS extensions API, ALPN and HTTP 2.0

[Simone Bordet]

See also: https://github.com/http2/http2-spec/issues/612

On Wed, Sep 17, 2014 at 3:17 PM, Simone Bordet <simone.bordet at gmail.com> wrote:
> Hi,
>
> On Wed, Sep 17, 2014 at 12:57 PM, Michael McMahon
> <michael.x.mcmahon at oracle.com> wrote:
>> 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.
>
> Indeed they should be independent, but section 9.2.2 poses constraint
> and links the h2 protocol with a particular subset of ciphers.
>
> The client can offer 2 ciphers, cipher1 that is valid per 9.2.2 and
> will work for h2, and cipher2 that is not valid for h2, but will work
> for http/1.1.
>
> At this point, the server has to have a knowledge about what ciphers
> are good for what protocol.
> Writing this code in a future-proof way is difficult.
>
> Even preferring client ciphers, which is only possible in JDK 8, is
> not enough, as we may choose the wrong one if the client sends them
> without a particular order.
> For example two browsers may send one (cipher1, cipher2), and another
> (cipher2, cipher1).
>
> Say that in future cipher FOO is discovered and found to be suitable for h2.
> An old h2 client is not aware of FOO, and won't accept it as valid for h2.
> But when the old h2 client is deployed in JDK 9, which does offer FOO,
> a server can select FOO because the client offered it, negotiate h2,
> but the client will close the connection because it won't recognize
> FOO as a valid cipher for h2.
>
> My statement about the difficulty of implementation went a bit beyond
> about strictly ALPN, but also taking in account server implementations
> of h2.
>
> We are trying to have section 9.2.2 modified so that it drops this
> linking and leaves everything to TLS (for example by just stating that
> a particular version (or greater) of TLS is mandatory for h2, without
> mentioning ciphers).
>
> For reference the discussion happens at
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/2112.html.
>
> --
> 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



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