- From: Greg Wilkins <gregw@intalio.com>
- Date: Wed, 24 Sep 2014 04:36:27 +1000
- To: Eric Rescorla <ekr@rtfm.com>
- Cc: Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAH_y2NE3d4pGyTOonR6h6t98eB-ydKU3GdQ8x-JEjVUK7Nv+4g@mail.gmail.com>
On 23 September 2014 18:30, Eric Rescorla <ekr@rtfm.com> wrote: > > You've offered this argument a number of times, > sorry for this. > but I'm still not understanding > how this happens. > which is why I keep repeating my attempt to explain it. > This leaves us with two things that can cause disagreement. > > - We might introduce a new cipher suite. > - We might retroactively reclassify an old one. > > In the former case, we should identify whether new cipher suites are > acceptable. > This could either be by making them match the characteristics in 9.2.2 > (PFS + AEAD) or by explicitly saying they are OK. In either case, when > implementations add these cipher suites, they should know if they are > acceptable so you shouldn't have disagreement. > No they can't. Let's say a server has kept up to date with the latest h2 acceptable ciphers, as have the majority of browsers. The server then sees a handshake with the new XYZ cipher in it. Because of the poor handshake design, the server does not know if the client is offering XYZ as a h2 acceptable cipher or simply because it was added to the clients cipher list but the client has not yet been updated to know it is h2 acceptable - and thus will reject a h2 connection that uses it. If the answer to this is to make h2 clients not offer new ciphers provided by their infrastructure until such time as their h2 impl is updated, then 9.2.2 will work in the opposite way to what is intended and will eventually discourage adoption of new ciphers as it will require updates to application protocols as well. If we are to do social engineering of the cipher selection, can we at least design a robust handshake. Having clients hide information on the assumption the server will work it out is just not a robust protocol design. regards -- 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 Tuesday, 23 September 2014 18:36:56 UTC