- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 21 Nov 2014 12:59:52 +1100
- To: Michael Sweet <msweet@apple.com>
- Cc: HTTP <ietf-http-wg@w3.org>
Michael, > On 18 Nov 2014, at 11:23 pm, Michael Sweet <msweet@apple.com> wrote: > > Mark, > > I've posted this to the issue as well... > > I am concerned that we are backing ourselves into a corner here - as written, INADEQUATE_SECURITY can only be used to enforce the blacklist provided in this spec, so the error might as well be called "USE_HTTP_1_1" because that will be the result. > > If, however, we want to allow INADEQUATE_SECURITY for any situation where the client or server policy prohibits the use of certain cipher suites for HTTP/2 (with the default policy being the blacklist in the spec), then this language needs to be re-worded accordingly, e.g., "Endpoints MAY choose to generate a connection error of type INADEQUATE_SECURITY if the negotiated cipher suite does not meet the endpoint's minimum security requirements. The default security requirements MUST enforce the prohibited list of cipher suites." That's not the semantic that we're giving INADEQUATE_SECURITY, and the current use case -- informing an implementation that they're not conforming to the spec'd requirement, and therefore the client is closing the connection -- is legitimate on its own, because (as many have pointed out) USE_HTTP_1_1 used in this fashion can be viewed as a downgrade attack. If you want to close a connection because it doesn't meet some *other*, implementation-specific requirement, you're able to do so already; if you want to flag that with an error code, you can use another error code. I don't detect any appetite in the rest of the WG for defining that now, however. > We should probably also better document INADEQUATE_SECURITY in section 7, something like: "The negotiated TLS cipher suite does not meet minimum security requirements (see Section 9.2)." It's used for other things too... > Finally, we should say something about why we need this functionality: endpoints typically will support both HTTP/1.1 and HTTP/2, and TLS does not allow either endpoint to restrict the list of negotiated cipher suites based on the ALPN negotiated protocol (i.e. ALPN just allows the client to send a list of protocol identifiers, not identifiers + cipher suites). I think that's good editorial input for Martin. Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Friday, 21 November 2014 02:00:19 UTC