W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: 9.2.2 Cipher fallback and FF<->Jetty interop problem

From: Greg Wilkins <gregw@intalio.com>
Date: Sat, 6 Sep 2014 14:34:58 +1000
Message-ID: <CAH_y2NFLjok-NRJtOw1vmSy68sf393iSOgA4K599q0BSBqbNgA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 6 September 2014 09:35, Martin Thomson <martin.thomson@gmail.com> wrote:

> You shouldn't have to.  Have you tried my suggestions at all?

I've not tried your suggestion because it is not available on JDK7.

Besides, my concern is not about how to make my implementation work, I'm
aware of
several fiddles I can do to make a good cipher be selected.

My concern is that implementations which comply with the relevant RFCs can
be put
together and not work.  There should be no need of fiddling functionality
outside of the
scope of the RFCs to make them work.

9.2.2 wants the server to select an acceptable protocol/cipher
combination,  but there
is nothing in RFC7301 that requires cipher/protocol selection functionality
to be offered by a ALPN extension. ALPN is not an extension for cipher

So 9.2.2 may not be implemented for those that are not implementing the
entire stack
themselves.You can't just say it is fixed because some can hack outside of
the scope
of the RFCs to pick an acceptable cipher/protocol combination.  Compliant
implementations may not offer that functionality.

If you want a TLS extension that can negotiate cipher AND protocol, then
than needs
to be described in an RFC.     We can write something today that works, but
it will be
operating outside of the standards.

As the draft explains, clients will still need to offer those insecure
> ciphers for HTTP/1.1 backwards compatibility.

Client and server already negotiate the most preferable common cipher.  How
adding protocol to that already accepted selection mechanism influence the
deprecation of poor ciphers in any way?

If you want to stop old servers using poor ciphers, then the clients should
offering those ciphers.   Talking h1 instead of h2 does not make the
any more secure and doesn't influence the server in anyway at all because it
doesn't offer h2 anyway.

All we are doing is hindering the deployment of h2 in environments that may
limited scope to enhance/deprecate/update their ciphers or the cipher

Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.
Received on Saturday, 6 September 2014 04:35:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:37 UTC