TLS extensions API, ALPN and HTTP 2.0

[Michael McMahon]

Okay, I see the point you are making. It's more a question of whether
the constraints themselves are appropriate.

I've another question. In the work you've done so far, did you allow
for the possibility of separate certificates to be selected per ALPN 
instance?

I'm guessing that if multiple applications are to be supported
over one TCP port (client or server) then different certificates might be
needed for each application. Or is that not a reasonable assumption?

Thanks,
Michael

On 17/09/14 14:18, Simone Bordet wrote:
> 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
>
>