Re: #612: 9.2.2 requirements

On 1 November 2014 05:35, Mark Nottingham <mnot@mnot.net> wrote:

>
> The fundamental technical issue — publishing a protocol standard that
> allows cipher suites that we know to be insecure — has not been addressed.
>


Just to double down....  How do you reconcile the position above with the
text in 9.2.2 that says:

   Clients MAY advertise support of cipher suites that are prohibited by
   the above restrictions in order to allow for connection to servers
   that do not support HTTP/2.  This enables a fallback to protocols
   without these constraints without the additional latency imposed by
   using a separate connection for fallback.

If it is not acceptable for a newly published protocol standard to allow
known insecure ciphers, then it is not acceptable for such ciphers to be
offered in a handshake that is offering h2 - full stop.      Why are we
making our handshake fragile for all time, just so we can avoid "additional
latency" for known insecure ciphers.

Remove that paragraph and I'm basically happy - modulo any improvements in
the cipher restriction text being discussed here.

cheers





-- 
Greg Wilkins <gregw@intalio.com>  @  Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.