- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 20 Mar 2014 11:47:51 +1100
- To: "William Chan (陈智昌)" <willchan@chromium.org>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 20 Mar 2014, at 11:38 am, William Chan (陈智昌) <willchan@chromium.org> wrote: >> No, we discussed it pretty extensively; look at the minutes: >> https://github.com/http2/wg_materials/blob/master/ietf89/minutes.md#315-http-uris-over-tls >> https://github.com/http2/wg_materials/blob/master/ietf89/minutes.md#alt-svc-http-header-field >> https://github.com/http2/wg_materials/blob/master/ietf89/minutes.md#discovery-of-tls-support-for-http-uris > > I don't know if we can in good faith claim that we discussed using TLS with http:// URIs in any detail. Again, we can have more discussion if you think it will help; however, I don't see the positions on either side changing in the timeline we're trying to meet. > I do recall very clearly that Pat wanted to discuss this further, but we moved forward to cover new topics like load assymetry. For the first section about http:// URIs over TLS, a lot of that was just me confirming that Chrome had indeed experimented with this and it is feasible in terms of deployment. I hope no one interpreted that as my supporting opportunistic encryption. I don't think that's the case, and I think everyone understands that Chrome doesn't want to do this. >> My impression at the meeting was that we roughly agreed to document how to use TLS for http:// URIs without requiring it, which means we need the Alt-Svc header. I discussed this with Martin and Julian, and we agreed that we'd put that in the alt-svc document, since it's separable (and potentially applicable to HTTP/1 for other use cases); that is what we're about to propose to the WG. > > Agreeing to documenting it doesn't mean agreeing to it being a normative reference in HTTP/2. If that is the case, then I must say that it was not clear at the session and should be rediscussed on the mailing list. We're going to propose that the alt-svc draft be a normative reference in HTTP/2 because the ALTSVC frame uses the concepts in there, not for any other reason. If you look at the -04 version of the alt-svc draft, you'll see that opportunistic / http://-over-TLS isn't mentioned, except for a very indirect one-sentence reference to the use case in the Introduction. Nor does it require implementation of or support for the Alt-Svc HTTP header field. Given that, are you still concerned about the reference? >> From a judging consensus standpoint -- of course we can talk about it more. However, I will note that there's a *significant* amount of interest in this mechanism from many in the security community, we have an implementation in one major browser, and it's not required to implement or use. So, my feeling is that an argument to omit it from the document is going to need to be a very persuasive one -- one that's stronger than "we think it's a bad idea." >> >> One way to do that would be to get "don't do this" advice from the Security Area, but so far all of the input I've had from that direction is "do this." > > I agree that it'd be a tall order to refuse to outright document it at all, given the interest. I'm more concerned with the perception that HTTP/2 is explicitly supporting opportunistic encryption, which we clearly did not agree to in Zurich. Not sure how Zurich comes into it; London is the most recent meeting where this was discussed. > An independent document clearly decoupled from HTTP/2 would ..? -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 20 March 2014 00:48:17 UTC