- From: Greg Wilkins <gregw@intalio.com>
- Date: Sat, 6 Sep 2014 14:34:58 +1000
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAH_y2NFLjok-NRJtOw1vmSy68sf393iSOgA4K599q0BSBqbNgA@mail.gmail.com>
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 negotiation. 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 ALPN 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 does 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 stop offering those ciphers. Talking h1 instead of h2 does not make the conversation 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 have limited scope to enhance/deprecate/update their ciphers or the cipher selection algorithm. -- 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