RE: 9.2.2, Rough Consensus, and Working Code

You keep sending a new e-mail, and I keep rebasing my replies....  :-)  Your interpretation is mostly correct, except that we don't plan to make the investment to *enforce* compliance by the other party, which the spec currently requires.  We disagree with requiring enforcement, and would remove that MUST.  But if there's no required enforcement, then the others aren't really MUSTs, either.  All of the edits in my pull request flow from that single difference.

Why only clients send INADEQUATE_SECURITY?  The client knows what it offered and what that resulted in on the server -- if it doesn't like the outcome, it can notify the server that it's closing the connection and try again with a different offer.  The server, on the other hand, doesn't have a path forward if it sends INADEQUATE_SECURITY.  If it rejects the client's security settings, the client can't know for sure what configuration the server would accept -- that seems the very definition of Greg's "fragile handshake."  At that point, you're not negotiating, you're playing Twenty Questions, guessing at the overlap of the TLS-layer config and the HTTP-layer config.

Regardless of protocol selection, the server should only ever accept a cipher suite it's willing to use, and should pick the most preferred cipher suite the client offers.  (And by the HTTP/2 spec, we know that it will support at least one hopefully-still-good cipher if it's offering HTTP/2.)  We don't need HTTP-layer logic to do that -- that's how the TLS stack works today.

I think our underlying differences in this discussion are:
    - Should an HTTP/2-capable server *refuse* to speak HTTP/2 with an HTTP/2-capable client because the client's best cipher suite is too low on its own preference list, but still acceptable per its TLS configuration?
    - Should there be an HTTPbis-mandated TLS configuration that either subsets or constrains local TLS configuration?

We believe not, on both counts.

-----Original Message-----
From: Mark Nottingham [mailto:mnot@mnot.net] 
Sent: Wednesday, November 5, 2014 3:26 PM
To: Mike Bishop
Cc: HTTP Working Group
Subject: 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:39:42 UTC