Re: New Version Notification for draft-nottingham-http2-encryption-00.txt

On Tue, Oct 8, 2013 at 3:53 PM, Mark Nottingham <mnot@mnot.net> wrote:

> Hey Will,
>
> Answers below. It'd be nice if you GMail folks could do proper quoting...
>

Sorry about that. Let me go uncheck the "annoy mnot by screwing up quoting"
option in GMail. I swear it's here somewhere...wish they could stop
changing the UI so I could find it.

Btw, let me reiterate that I think the proposal has a lot of good points,
so people don't get confused by my selection bias in what I'm commenting
on. I definitely think there's a lot of interesting stuff in this I-D to
consider.


>
> On 08/10/2013, at 1:26 PM, William Chan (陈智昌) <willchan@chromium.org>
> wrote:
> >
> > > * Alternate-Protocol at first led to a performance hit on cold page
> loads because after the initial HTTP request, a warm HTTP connection is
> available, whereas the establishing of a SPDY connection only happens when
> the next resource load begins, after a A-P response header was received.
> This incurs the latency cost of connection setup for the new SPDY
> connection. We fixed this by racing HTTP and the alternate protocol
> connection. This achieves the performance goal, but increases the "gap"
> that you mention in section 3.4.
> >
> > Alt-Svc introduces an explicit freshness lifetime for the association
> between the origin and the alternate service(s) advertised, to help
> mitigate this.
> >
> > I don't understand this. Can you explain further? Just in case my
> problem description wasn't clear, let me restate:
> >
> > Cold page load
> > ==> GET /index.html (occurs over newly established HTTP/1.X connection)
> > <== index.html + Alt-Svc: http2-tls=:443
> > ==> GET /foo.jpg (Does the user-agent block the foo.jpg fetch on a new
> HTTP/2 over TLS connection? If so, that's a perf hit, since there's a
> HTTP/1.X connection warm and ready to go.)
> >
> > For SPDY with A-P, we will send all subsequent fetches to the host over
> existing HTTP/1.X connections, but once a new SPDY connection becomes
> available, we'll switch the fetches over to the SPDY connection. This
> avoids paying the SPDY connection setup cost, at the cost of sending some
> number of fetches over HTTP/1.X rather than SPDY.
>
> Right now the spec doesn't require the client to do either; a
> security-sensitive client might decide to wait, while a pert-minded one
> will still use HTTP1.x until 2.x is ready to go.
>

SGTM. It's probably worth discussing and clients can figure out whatever
they think is appropriate.


>
> The difference is that Alt-Svc allows you to do remember the alternate
> service for a protocol-defined amount of time (the ma parameter), so that
> you can skip the HTTP/1 step if you've previously connected to the origin
> before and the alt-svc is still fresh.
>

Chromium persists A-P as well (even though it's not specced, lol, SPDY is
awesome!), but it also has the mistake of not specifying the freshness. I
approve of that mechanism in Alt-Svc.


>
> > Note, this also complicates analytics accounting. How do you rate the
> performance of a mixed protocol page load?
>
> Yes, life is hard for analytics people.


>
> >  > * What's your thought on whether or not this should be per-hop? There
> are interesting interactions with CDNs:
> https://code.google.com/p/chromium/issues/detail?id=288992.
> >
> > My draft makes it an alternate service a property of the origin, so it's
> end-to-end (in RFC2616 terms). I think that's appropriate; CDNs *are* the
> origin, as far as HTTP is concerned (technically, they're a gateway), and
> they need to act accordingly; e.g., Host header checking, as well as stuff
> like this.
> >
> > While that's reasonable, it makes this difficult to roll out. The CDN in
> this example wasn't aware of the Alternate-Protocol header, and the default
> behavior is to pass through unknown headers. I would expect Alt-Svc to have
> the same issue, which complicates deployment.
>
> As an ad hoc mechanism, it is indeed quite bothersome. If we standardise
> it and it becomes well-understood, that problem largely goes away. The
> mitigation is pretty simple.


>
> >  In general, I think there are a lot of aspects of HTTP2 we're going to
> need to tighten up WRT intermediaries, but that's a separate discussion...
> >
> > > * It looks to me like Alt-Svc's extra capability (in comparison to
> A-P) of specifying a different hostname seems to open up the possibility of
> a poisoning attack. Did anyone mention this yet? I didn't see it in the
> I-D. It seems like if you can actively attack the client's connection to
> victim.com once and inject an Alt-Svc for evil.com, then evil.com can
> persistently mitm that client even if later on it's not directly on the
> network path between the client and victim.com.
> >
> > """
> > Clients MUST NOT use alternate services on a host other than the origin's
> > without strong server authentication; one way to achieve this is for the
> > alternate to use TLS with a certificate that is valid for that origin.
> >
> > For example, if the origin's host is "www.example.com" and an alternate
> is
> > offered on "other.example.com" with the "http2-tls" protocol, and the
> > certificate offered is valid for "www.example.com", the client can use
> the
> > alternate. However, if "other.example.com" is offered with the "http2"
> > protocol, the client cannot use it, because there is no mechanism in that
> > protocol to establish strong server authentication.
> > """
> >
> > OK, security novice here, but why does strong authentication matter
> here? If I get you to persistently send foo.com's traffic to an
> authenticated evil.com, isn't that still bad?
>
> Strong authentication of the *origin*, not the alternate service. I.e.,
> the alternate has to prove it holds an identity for the origin it's serving.
>

Aha, sorry, I skimmed that text too quickly. Was non-obvious until you
pointed it out. But I should probably not drink before reading your text
and then maybe it'd be easier for me to grok.


>
>
> >  > * I think I skimmed someone mentioning UI indicators. I don't think
> browsers would change the UI indicator for the Alt-Svc. It's likely that
> we'd just keep the same UI indicator based on the requested URI. If we get
> enhanced security properties for http:// URIs, we'll take the free
> awesomeness, but probably not indicate it in the UI.
> >
> > Yes, the draft talks about it, and I agree with your position:
> >
> > Awesome. I agree with myself too.
>
> Good to know the universe is still well.
>

It'd be better if the universe agreed with me too.


>
>
> >  """
> > When the http2-tls-relaxed protocol is in use, User Agents MUST NOT
> indicate
> > the connection has the same level of security as https:// (e.g. using a
> "lock
> > device").
> > """
> >
> > There's also:
> >
> > """
> > Importantly, this includes the security context of the connection; by
> default,
> > the alternate server will need to present a certificate for the origin's
> host
> > name, not that of the alternate. Likewise, the Host header is still
> derived from
> > the origin, not the alternate service.
> >
> > The changes SHOULD, however, be made visible in debugging tools,
> consoles, etc.
> > """
> >
> > > * Does this I-D say anything about what happens if the Alt-Svc
> response header appears on a https:// URI? I think it's a bad idea for a
> client to respect it. I'd be worried about making a one-time MITM attack
> become persistent due to poisoning.
> >
> > """
> > Furthermore, because different protocols can have different security
> > properties, clients ought not blindly use alternate services, but
> instead they
> > option(s) presented for conformance to implementation policy, user
> preferences,
> > and general security.
> >
> > For example, in theory the header field could be used to advertise a
> downgrade
> > to plain TCP from a TLS-protected connection, or to relax certificate
> checks
> > for a HTTPS URI; opting to use such an alternate would seldom be
> desirable.
> > """
> >
> > Ah, interesting. Yes, that's an even more nefarious thing to do. I
> wasn't thinking about downgrade attacks though. I was thinking about
> https:// => Alt-Svc: http2-tls=evil.com:443. I suspect that's also never
> desirable.
>
> See restrictions above.
>
> Cheers,
>
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>