Re: http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc as a normative reference in http/2

On Wed, Mar 19, 2014 at 5:47 PM, Mark Nottingham <mnot@mnot.net> wrote:

> 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 agree that positions are unlikely to change. Therefore, I'm surprised
that the evaluation of the consensus has changed from Zurich to London. If
this was actually what we were discussing in httpbis in London, I do not
think it was clear to everyone present.


>
> > 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?
>

This mitigates my concerns greatly. I eagerly await the next version of the
draft so I can comment on it more definitively.


>
> >>  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.
>

It's because of what I said before - I don't think it was actually
discussed in any real detail in London. I very distinctly remember Pat
saying we should discussing opportunistic encryption in the httpbis session
and getting tabled. And I know several people who were confused about
whether or not there was an appropriate time to raise opportunistic
encryption as a topic of discussion.


>
>
> > An independent document clearly decoupled from HTTP/2 would
>
> ..?
>

If we have any document describing how to do opportunistic encryption, I
don't want it normatively referenced from HTTP/2. That's just my personal
opinion. But I personally don't think there was consensus in London for
this either, which is why I sent my email primarily to see if there was
indeed consensus.


>
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>