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.