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

Hey Mark,

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

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

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