Re: Discussion of 9.2.2

On 26 September 2014 03:05, Eric Rescorla <ekr@rtfm.com> wrote:

> Isn't that only true if we add a new non-AEAD ciphersuite in NSS and then
> forget
> to update the code in Firefox?
>


Let's say that a new non-AEAD cipher is added in the future.  At some point
in time there is going to be a split population of FF deployed, some that
do know about it and some that don't.   Those that don't might still offer
the cipher because it is a good desirable cipher for h1.   So we are back
to servers not knowing if a client is offering a cipher as a h2 acceptable
one or not.

Now judging from Patrick's response in this thread, it might not be a
problem for FF if they have to explicitly white list new ciphers (so they
can change that code at the same), but it may be that new ciphers are added
to FF by plugin or other configurations. Also, other clients may not be so
rigorous about vetting new ciphers, and may still have the same isAEAD()
test instead of the more correct !isBlock()&&!isStream()

A handshake that relies on good cipher vetting of the client to work is a
fragile handshake.

The point being that the current text in 9.2.2 encourages implementations
to tread AEAD as a sufficient and necessary condition for a cipher, when in
fact it is just sufficient and not necessary.  If 9.2.2 explicitly said how
future new classes of ciphers should be handled, then we'd avoid this.

cheers




-- 
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.