Re: 9.2.2, Rough Consensus, and Working Code

Thinking about this a bit more --

> On 5 Nov 2014, at 12:42 pm, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
> 
> Microsoft also has no current plans to implement the restrictions of 9.2.2 in client or server stacks.  We fully support this guidance as a best practice, and our default configuration will be compliant 99+% of the time.  However, we don’t wish to restrict the admin’s ability to change the default configuration based on local knowledge or our ability to change the defaults in the future based on new information.

So, I interpret that as "Microsoft will ship a product that is *able* to be conformant, and will by default and also very often actually be conformant, but it will be possible for an admin to configure it in a way that is non-conformant."

If that's roughly true, I personally think that's OK, and not even unusual or even remarkable for products that implement IETF protocols. Thoughts?

> Jason has described the abilities that would have to be added to TLS (http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0108.html) to support the proposed requirements, which are essentially that ALPN selection implies restrictions to the cipher suite selection (or vice versa).  There’s nothing in the TLS or ALPN docs that suggests cipher suite selection has anything to do with ALPN protocol selection.  We still believe that documents specifying new TLS behavior should come from the TLS WG and be implemented in the TLS stack.

That's one possible implementation technique to enable conformance. Another is to use cipher suite preferences, as many are now doing. How is that inadequate?

> I’ve given RFC 7282 a read (and anyone who hasn’t done so this week, please do), and I personally have to concur with Martin’s assessment – we have no consensus to keep 9.2.2 in the spec as written.  However, I also believe Mark is correct that there remains a valid objection from those who want to see it included (including some outside this WG).
>  
> I believe our best path forward is to keep 9.2.2, but relax the MUSTs to SHOULDs.  I’ve prepared a pull request to this effect athttps://github.com/http2/http2-spec/pull/641.  Either TLS implementation is free to only offer or accept cipher suites they’re comfortable with, regardless of protocol, but there is no technical reason that these cipher suites are the only ones that MUST ever be used when HTTP/2 over cleartext is acceptable and HTTP/1.1 over other cipher suites is acceptable.

I'm concerned that relaxing those requirements will actually make it *more* likely that we'll see interop problems; as discussed, implementations that conform to the proposed text ought not encounter any interop issues, but if we make those SHOULDs, we're creating Greg's "brittle handshake."

Cheers,

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

Received on Wednesday, 5 November 2014 23:26:07 UTC