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.bor...@gmail.com> wrote:
Hi,
On Wed, Sep 17, 2014 at 12:57 PM, Michael McMahon
<michael.x.mcma...@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
