Re: #612: 9.2.2 requirements

Mark,

your response is a whole bunch of straw men.  You are talking about things
that I am just not proposing.


On 6 November 2014 10:19, Mark Nottingham <mnot@mnot.net> wrote:

> Greg,
>
> We're here to define HTTP/2, not redefine HTTP/1. The time to make this
> argument was during bis, and I suspect it would have had a similar
> reaction; we can't put new requirements on the existing, deployed Web.
>
>
I am not suggesting that we  redefine HTTP/1

I'm saying that in the brand new http2 handshake that we are defining,
there is no need to support weak ciphers and old protocols.  If clients
wish to talk weak ciphers to old protocols, they are free to retry
connections using the existing http/1 protocol unchanged.

More to the point, prescribing fallback / retry behaviours is something
> that HTTP has historically avoided, for good reason; it's up to a client
> when and how they retry a request, and they may (for good reason) use
> different approaches. We're here to define how all HTTP implementations
> behave, not just browsers.
>

I'm not prescribing fallback (I did propose that previously but not now).
I endorse Martins text in his PR that simply says that retries may be done,
with suitable warnings about downgrade attacks.     All I'm currently
advocating is that we do not support weak ciphers in the new h2 handshake.

"Lack of expressive capability" is not necessarily an interoperability
> problem. Likewise, as per above failing to make a connection is always a
> possible end state, if the client and server can't agree on requirements.
>
> The interoperability problem is that the client and server may share an
acceptable protocol/cipher pair, but the handshake may fail to negotiate
that.     Connection failure is fine IFF there is no acceptable
cipher/protocol pair.


> However, it still hasn't been shown how this will be the case with HTTP/2,
> if both the client and server are conformant to the proposed text.
>

The situation has been described many times in many variations.   One such
situation is if the server does not have access to the details of the
cipher and only knows it's name.  Then it's 9.2.2 implementation will most
likely be done by white/black lists and/or regular expression matching on
the name.    Such an approach will not be perfect in the face of future
cipher development (the XYZ cipher), thus there is always the opportunity
for differences in 9.2.2 implementation when being updated for new ciphers
and thus the hand shake can fail.


> Do you really think that this WG can declare widely deployed cipher suites
> as non-conformant in HTTP/1, and browsers will just start refusing to
> interoperate with those servers?
>

I'm not saying that at all.   I'm saying that we should not support known
weak ciphers in the new h2 handshake.     Browser making connections using
http1 are free to continue doing whatever they have been doing.

Fundamentally it is a misuse of ALPN for the client to advertise support
for a cipher that is subsequently rejects as inadequate security for the
protocols included in the ALPN handshake.  If you REALLY want to avoid any
increase in latency for talking weak ciphers to old servers, then you need
to come up with an enhancement proposal for ALPN that allows ciphers sets
per offered protocol.

> Remove that paragraph and I'm basically happy - modulo any improvements
> in the cipher restriction text being discussed here.
>
> Greg, with all respect, we're not here to make all participants happy --
> it is a completely normal end-state in the IETF for many to be unhappy.
> What we need to do is address technical issues that are brought to our
> attention.
>

C'mon mate! don't get hung up on a turn of phrase.         I have been
raising technical objections.   Removing the weak ciphers from the h2 ALPN
handshake addresses my technical objections... which I would make me
happy.

regards



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