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:17 PM, Mark Nottingham <mnot@mnot.net> wrote:

>
> On 20 Mar 2014, at 5:54 am, William Chan (陈智昌) <willchan@chromium.org>
> wrote:
>
> > There was some discussion about this at the IETF89 httpbis session, and
> I see that there's an altsvc branch in the github http2 repo (
> https://github.com/http2/http2-spec/commits/altsvc) with a commit (
> https://github.com/http2/http2-spec/commit/0afe05385c2a521079ba3874a20a21ebb1debd99)
> that marks this draft as a normative reference.
>
> There's also a revised httpbis-alt-svc in the works:
>   https://github.com/mnot/I-D/tree/master/httpbis-alt-svc
>
> ... which you really need to read when looking at that branch.
>
> Neither has yet been brought to the WG; I'm still working on them in
> consultation with Martin, Patrick and Julian (but almost done).
>

Ah, fair enough.


>
>
> > I wanted to doublecheck what peoples' thoughts on this matter were. I
> feel like there was some form of rough consensus assessed in the session,
> although the exact details were very ambiguous to me. Currently the alt-svc
> draft lists 4 use cases that could be addressed with various proposals:
> >
> > (1) Upgrading HTTP/1 (" The first use case for Alternate Services is
> upgrading a client from HTTP/1 to HTTP/2 for http:// URIs (i.e., without
> the use of SSL or TLS).") as an alternative to HTTP Upgrade.
> > (2) Using TLS with http:// URIs
> > (3) Mitigating Load Asymmetry
> > (4) Segmenting Clients that Support TLS SNI
> >
> > There are two mechanisms proposed for addressing these use cases. They
> are the ALTSVC HTTP/2 frame and Alt-Svc HTTP response header.
> >
> > My personal gauge of the rough consensus at the IETF89 httpbis session
> was there was rough consensus for meeting use cases (3) and (4), both of
> which require the ALTSVC frame, but not the Alt-Svc response header.
> Furthermore, I think there was rough consensus around incorporating the
> ALTSVC frame directly into the core HTTP/2 spec, although I remember Rob's
> disagreement here (thinking that we should bring back extensible frames,
> and if that doesn't get in, we use should MAY rather than SHOULD in the
> spec as to how clients should handle this advisory frame).
> >
> > I think that use case (1) did not get discussed at all
>
> Correct. I suspect we'll get to that, if the folks who are interested in
> doing h2c want to.
>
>
> > , and (2) got raised very briefly by Pat, but tabled due to lack of time.
>
> 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. 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.


>
>
> > Both these use cases rely on the Alt-Svc HTTP response header. I
> therefore do not believe there's a rough consensus on including the Alt-Svc
> HTTP response header. But perhaps further discussion will reach such a
> consensus.
>
> 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.


>
> 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. An independent document clearly decoupled from HTTP/2
would


>
>
> > I'd like to hear thoughts from folks on, what parts of the alt-svc draft
> would be acceptable for inclusion in the HTTP/2 core spec or as a normative
> reference.
> >
> > FWIW, my thought would be to include the ALTSVC frame in the core spec,
> with a normative reference to a standalone specification of section 3.1 in
> the alt-svc draft.
>
> Will, please be patient and wait until we actually have a proposal (a few
> hours to a day, I think); basing discussion on work-in-progress is not
> going to be helpful.
>

I think you perceived my mentioning of your commits as me impatiently
responding to something that's in progress. If so, then that's an error. My
email was more in response to comments I've heard in response to your blog
post about HTTP/2 supporting opportunistic encryption. There is wide
confusion about this, therefore I felt compelled to ask what we have
actually achieved consensus on. I just happened to see your commits when I
was searching for the latest status of how Alt-Svc is referenced in the
HTTP/2 spec. I actually didn't know you had a branch until earlier today.


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