Re: #612: 9.2.2 requirements

Greg,

On 5 Nov 2014, at 12:13 pm, Greg Wilkins <gregw@intalio.com> wrote:
> 
> 
> On 1 November 2014 05:35, Mark Nottingham <mnot@mnot.net> wrote:
>> While some may consider the handshake “fragile”, they’ll need to explain how — given the above context — it affects interoperability in a way that’s significant. So far, I haven’t seen an explanation of how the handshake raises such an issue.
> 
> The problem with 9.2.2 is not that it tries to restrict TLS ciphers to known good ciphers.   It is that is also tries to allow clients to continue using known poor ciphers with http1 without any penalty.
> 
> If we all collectively just grew a pair and said that known bad ciphers are not acceptable for HTTP (regardless of version) then the handshake would not be fragile.

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. 

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.


> The interoperability problem comes because the handshake does not have the expressive capability to clearly identify which ciphers are being offered for h2 and which ciphers are being offered for h1 fallback to bad ciphers.      This allows the handshake to fail when there is a mutually acceptable  pairing of protocol and cipher.

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

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

We are also publishing a protocol that needs a realistic chance of transitioning from HTTP/1. Your statement before:

> The argument against this is that suffering an extra round trip is unacceptable for the clients that wish to talk to these old weak servers.     I believe that continuing to talk to such servers is unacceptable, but if you really have to do it, then adding the round trip is a good incentive to update ciphers/protocols.

is quite revealing. 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? 

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

Regards,


--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 5 November 2014 23:19:42 UTC