- From: Greg Wilkins <gregw@intalio.com>
- Date: Thu, 18 Sep 2014 10:09:54 +1000
- To: Brian Smith <brian@briansmith.org>
- Cc: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAH_y2NEhAEaPiUgi_vX6Oimw+Y-k3WrnL0gJZKPxQ8KZVuFVfw@mail.gmail.com>
On 18 September 2014 05:02, Brian Smith <brian@briansmith.org> wrote: > draft 14 is clear enough for me to classify cipher suites into > "acceptable" and "not acceptable". By default, assume that a cipher > suite is not acceptable and you'll be fine. So tell me how 9.2.2 defines the handling for the following situation. Consider clients and servers written in java, so they inherit their ciphers from the JVM. At some stage in the future a GCM is replaced by XYZ and added to the JVM, so it is part of the acceptable TLS ciphers, but the h2 clients and servers implementations have adopted your advice to "By default, assume that a cipher suite is not acceptable". So everybody is assuming that XYZ is not h2 acceptable. So firstly this could be a problem if XYZ was introduced because of a security flaw in GCM, as if implementation removed support for GCM, then we could see a mass fallback to http/1, because TLS would not negotiate a h2 acceptable cipher. But let's say that when this happens, we are smart and we work out that XYZ is acceptable for h2. So we are going to modify our implementations to also consider XYZ as h2 acceptable. When can the server deploy XYZ h2 acceptability? If it does so before the clients, then it will immediately lose connectivity with all clients. If it waits until all the clients are updated, then it will be waiting forever and the web will have reverted to http/1.1. If it goes in between, there will always be a large subset of clients where the failure mode is failed connection rather than fallback to old protocol or old cipher In short because of 9.2.2, there is no migration path to the new XYZ cipher that does not involve losing connectivity with a large proportion of clients. This is not a theoretical problem. It is a real problem that I have experienced as FF rolled out their AEAD restriction as rqeuired by 9.2.2 before jetty had implemented the same restriction and while AEAD is not available on java-7. I could implement the AEAD restriction in jetty now to get connectivity with FF, but would lose connectivity with h2 clients running java-7. -- 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 Thursday, 18 September 2014 00:10:23 UTC