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

On Tue, Oct 8, 2013 at 1:48 AM, Mark Nottingham <mnot@mnot.net> wrote:

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


Great. I didn't see the TODO but as long as this is on peoples' minds,
wonderful.


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

Note, this also complicates analytics accounting. How do you rate the
performance of a mixed protocol page load?


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


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


>
>

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


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


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