- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 6 Nov 2014 11:02:23 +1100
- To: Mike Bishop <Michael.Bishop@microsoft.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
> On 6 Nov 2014, at 10:39 am, Mike Bishop <Michael.Bishop@microsoft.com> wrote: > > 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. I kind of disagree with that last point; if the administrator is choosing cipher suites but the implementation decides when to send INADEQUATE_SECURITY, there are two different points of control, and it may make sense to diverge in requirement levels. So, maybe the path forward would be to leave the cipher suite requirements at MUST -- putting the responsibility for conforming on the administrator in some deployments -- but reduce the requirement to generate INADEQUATE_SECURITY to a SHOULD, thereby letting an implementation that doesn't have the ability (or desire) to enforce off the hook. Need to think through the implications of that, but WDYT? > 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. I interpret the server generating INADEQUATE_SECURITY as it saying "sorry, we can't talk, we're done." In some (hopefully rare) cases, that's entirely appropriate. -- Mark Nottingham https://www.mnot.net/
Received on Thursday, 6 November 2014 00:02:49 UTC