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

On 08/10/2013, at 8:40 PM, William Chan (陈智昌) <willchan@chromium.org> wrote:

> Hey Mark,

Hi Will,

> Thanks for putting together this proposal. I'm not up to date with this thread, and I've just skimmed your I-D. It looks very similar to the Alternate-Protocol work we proposed with SPDY (notably A-P retains the same hostname, whereas Alt-Svc can change it).

Absolutely.

> Toward the end, I have some questions/comments from stuff we've seen in Alternate-Protocol. Pardon me if it's addressed somewhere in your draft.

No worries.

> * What's the connection requirement of Alt-Svc? If a new service is offered, but the client fails to be able to connect, then what happens? Alternate-Protocol tackles this by only attempting to improve performance (by using SPDY, perhaps sharing a SPDY connection) and preventing passive attacks. But any active attacker is free to downgrade the Alternate-Protocol by killing the alternate connection, in which case, according to Alternate-Protocol's "spec", the user agent falls back to using the normal connection resolution process. I don't see anything in this I-D that specifies this behavior. Is it completely up to the user agent's discretion?

At this point, it's roughly equivalent to Alternate-Protocol. There's a TODO in the document as to whether this should be tightened up, and if so, how.

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

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

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


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

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

> 
> Hm, I ought to sleep. This is probably enough for now. Cheers.
> 
> 
> On Mon, Sep 30, 2013 at 5:54 PM, Mark Nottingham <mnot@mnot.net> wrote:
> Everyone,
> 
> This is a draft put together based upon my observations of our discussions about encryption and HTTP/2.0, both before and after Berlin, along with a fair dose of help from reviewers (thanks again!).
> 
> It proposes a way to optimistically encrypt communication for http:// URIs that is resistant to passive attacks, but is not (yet) resistant to active attacks. Full details are in the draft.
> 
> The aim was to respect the (sometimes conflicting) requirements of various stakeholders here; I may or may not have hit that goal, and look forward to the discussion. Really, the idea is to get the conversation going, not to guide us to a particular endpoint.
> 
> I understand that other folks might be working on complementary or competing drafts as well. We're not going to discuss this general area in any detail at our Seattle interim meeting; instead, we will have a substantial block of time set aside in Vancouver.
> 
> Regards,
> 
> P.S. I've attached a possibly friendlier HTML version.
> 
> 
> 
> 
> 
> Begin forwarded message:
> 
> > From: internet-drafts@ietf.org
> > Subject: New Version Notification for draft-nottingham-http2-encryption-00.txt
> > Date: 1 October 2013 10:45:04 AM AEST
> > To: Mark Nottingham <mnot@mnot.net>
> >
> >
> > A new version of I-D, draft-nottingham-http2-encryption-00.txt
> > has been successfully submitted by Mark Nottingham and posted to the
> > IETF repository.
> >
> > Filename:      draft-nottingham-http2-encryption
> > Revision:      00
> > Title:                 Encryption for HTTP URIs Using Alternate Services
> > Creation date:         2013-10-01
> > Group:                 Individual Submission
> > Number of pages: 15
> > URL:             http://www.ietf.org/internet-drafts/draft-nottingham-http2-encryption-00.txt
> > Status:          http://datatracker.ietf.org/doc/draft-nottingham-http2-encryption
> > Htmlized:        http://tools.ietf.org/html/draft-nottingham-http2-encryption-00
> >
> >
> > Abstract:
> >   This document proposes a way to optimistically encrypt HTTP/2.0 using
> >   TLS for HTTP URIs.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
> 
> 

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

Received on Tuesday, 8 October 2013 08:48:50 UTC