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

Hey Will,

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

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.

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.

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


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


>  """
> 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/

Received on Tuesday, 8 October 2013 22:54:03 UTC