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

From: Stefan Eissing <[email-masked]>
Date: Tue, 1 Oct 2013 10:52:07 +0200

Mark,

I like the approach to take the security aspect of the connection out of
the uri. Using the uri scheme to manage resource security is awkward. We
can expect security mechanisms to further evolve in the future and
need to disentangle this from the uri itself. (302-ing all google resources
works, but seems to indicate something's lacking here.)

As I was not part of the discussions so far, it may be total nonsense, but
would not a CONNECT against the server be a proper way to negotiate the 
security of the connection and perform possible upgrades to TLS or whatever?

Clients could send headers in the CONNECT indicating what security they 
are willing to accept, servers would send back in response what security 
the connection upgrades to then, if at all (come 4xx or 502 if they dont).

Performance wise this is no worse than sending an OPTIONS first. But has the
possibility to upgrade the existing connection.

Regards,

  Stefan

Am 01.10.2013 um 02:54 schrieb Mark Nottingham <[email-masked]>:

> 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.
> 
> <draft-nottingham-http2-encryption-00.html>
> 
> 
> Begin forwarded message:
> 
>> From: [email-masked]
>> Subject: New Version Notification for draft-nottingham-http2-encryption-00.txt
>> Date: 1 October 2013 10:45:04 AM AEST
>> To: Mark Nottingham <[email-masked]>
>> 
>> 
>> 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/
> 
> 
> 

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Tue, 1 Oct 2013 11:20:38 +0200

> Everyone,

Hi,

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

A few quick remarks:

1. your headers really need a lifetime declaration, like HSTS or DNS entries

2. you're making the web client an implicit proxy. Seems proxies are
useful after all:). However you really need to generalize the concept and
make it work with any proxy layer, be it the web client, some local OS
proxy lib, or a remote proxy. In particular any proxy will want to
consolidate all accesses to a single path to maximize caching

3. therefore the draft needs to clarify how the endpoint establishes trust
with a (possibly remote) proxy and how you avoid a situation where each
network layer tries to consolidate on a different network path

4. please make it explicit what granularity of caching do you allow. Is a
cacheable element identified by the network path used? Any network path
used? If I get an object from path foo, and then site bar tells me I am
authorized to use foo to fetch some objects, can I serve them from my foo
cache? Even if foo told me nothing before?

5. mirror and cdn people will really want a syntax that permits them to
tell all proxy layers they can use indiscriminately any mirror node for a
mirrored file (so they'll declare lots of http alternatives)

6. in case all the alternatives are not 100% trusted (sad fact of life),
can you define a method which which a downstream node can request a
checksum of the expected answer from the primary path? Like "you tell me I
can fetch this 4GiB file in http-tls from evilsite.com, can you at least
give me the checksum of the payload evilsite.com will serve me?" (and
possibly a list of checksums if it is known lots of elements are usually
processed together)

7. When given a list of alternate paths, I'd really like some hint on the
preferred paths according to my original contact (even if I choose to
ignore the hints for my own reasons). Load balancer people will want this

Regards,

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Tue, 1 Oct 2013 11:26:24 +0200

> security of the connection and perform possible upgrades to TLS or

Please not unless CONNECT changes drastically from a security point of
view. Right now every time an intermediary accepts a CONNECT it makes the
same mistake Richelieu made when he gave his full endorsement in writing
to Milady (that was ultimately used against both). CONNECT needs to be
extinguished not promoted

-- 
Nicolas Mailhot

---

From: Martin Thomson <[email-masked]>
Date: Tue, 1 Oct 2013 21:02:06 -0700

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

Having thought about this at great length, I wonder why Upgrade isn't
appropriate here, aside from the obvious deficiencies we've already
identified.  After all, we're already requiring the use of Upgrade for
HTTP/2.0 (at least for the in-the-clear cases).  The use of the header
seems unnecessary, and with the same-hostname restriction bound to it
(the escape clause too hand-wavey for me to take it seriously), it's
effectively the same.

I also wonder why you bothered to introduce the concept of a
"http2-tls-relaxed" profile.  To my mind, since the decision to use
TLS for the "http" resource was discretionary on the part of the
client, then the decision to validate the server certificate is
equally discretionary.  I would have thought that the logic would go
something like:

1. If https: then start with TLS from the outset
2. If http: then try to get to TLS somehow
3. If https: then make sure the certificate is good, fail if bad
4. make request
5. if https: display secure indicators

I don't see how anything that the server might say would affect this.
If the certificate is self-signed or otherwise not "good", then the
http requests simply won't block based on that.  That too is
discretionary.  I could imagine all sorts of other discretionary
measures that clients might take (like certificate pinning of a kind;
for instance, knowing that example.com always presents a genuine
certificate might cause alarm if they suddenly stop doing so).

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 6 Oct 2013 18:23:36 +1100

Hi Martin,

On 02/10/2013, at 2:02 PM, Martin Thomson <[email-masked]> wrote:

> identified.

What are you including in that?

The biggest for me is perf, and that's pretty much a showstopper.

>  After all, we're already requiring the use of Upgrade for

Sorry, you're going to have to expand that a bit. What escape clause is too hand-wavey?

> equally discretionary.  I would have thought that the logic would go

The server needs to know whether the cert is being validated (as discussed in a note near the end, there's more work to do on this). 

> certificate might cause alarm if they suddenly stop doing so).

Indeed.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 7 Oct 2013 08:13:30 -0700

On Sun, Oct 6, 2013 at 12:23 AM, Mark Nottingham <[email-masked]> wrote:

> The server needs to know whether the cert is being validated (as discussed
> in a note near the end, there's more work to do on this).
>

I'm not seeing that note; can you repeat the text here? Currently, the
server doesn't know whether the cert is validated: it could have been
accepted by clicking-through-the-UI-warnings.

If the HTTP server doesn't "need" to know whether the TLS client did the
validation, then there is no need for the "-relaxed" profile. If the HTTP
server really does need to know that, then we need a new TLS extension that
causes an validation indication to be passed through an API. That's much
more work than you are proposing here.

--Paul Hoffman

---

From: Mike Bishop <[email-masked]>
Date: Mon, 7 Oct 2013 15:33:44 +0000

I think the server's "need" stems from the multi-origin push discussion.  If the server is only allowed one cert and it's being validated, it can only push things matching that cert.  If the client only cares about encryption and not identity, then the server can push things for which it hasn't proven it's authoritative.

Sent from Windows Mail

From: Paul Hoffman<mailto:[email-masked]>
Sent: ?Monday?, ?October? ?7?, ?2013 ?8?:?17? ?AM
To: Mark Nottingham<mailto:[email-masked]>
Cc: Martin Thomson<mailto:[email-masked]>, HTTP Working Group<mailto:[email-masked]>

On Sun, Oct 6, 2013 at 12:23 AM, Mark Nottingham <[email-masked]<mailto:[email-masked]>> wrote:

I'm not seeing that note; can you repeat the text here? Currently, the server doesn't know whether the cert is validated: it could have been accepted by clicking-through-the-UI-warnings.

If the HTTP server doesn't "need" to know whether the TLS client did the validation, then there is no need for the "-relaxed" profile. If the HTTP server really does need to know that, then we need a new TLS extension that causes an validation indication to be passed through an API. That's much more work than you are proposing here.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 7 Oct 2013 08:57:57 -0700

If Mike's right, then the HTTP server needs to know *three* things from the
TLS layer:
1) Whether or not the client authenticated
2) If (1) is true, whether there is a host name was in the cert's identity
3) If both (1) and (2) are true, what the host name is
That seems like a lot of unstated assumptions.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 7 Oct 2013 16:14:09 +0000

On Oct 7, 2013, at 6:13 PM, Paul Hoffman <[email-masked]<mailto:[email-masked]>> wrote:

Suppose a server has a self-signed or self-issued certificate. Advertising "tls" would cause a client to start a TLS handshake, (maybe) attempt to validate the certificate, and fail miserably.

By advertising "tls-relaxed" but not "tls", the server can inform the client that using TLS will only for if the clients are willing to not be picky about the certificates.

In regular HTTPS the server does not need to know whether the client is doing any validation. For HTTP the server still doesn't need to know, but the client needs to know if the server is only advertising a willingness to encrypt or actual authenticated handshake.

Personally, I would prefer it if we didn't ask implementors to use certificates without validation. I'd rather that this be replaced with ADH ciphersuites without any certificate whatsoever. Anonymous certificates seem like a hack around the problem that browsers don't currently support ADH ciphersuites. But then, browsers don't support Alt-Svc either . I don't see why one feature is deemed easy to add, while the TLS ciphersuite is deemed hard. Using certificates has the advantage that you can use corporate CAs, so that some people can get a fully-validated session with mutual authentication, and others can get an anonymous session, and the server does not need to be able to tell them apart. I guess that's a reason.

Yoav

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 7 Oct 2013 10:00:10 -0700

We're talking around the same problem. What Mark has proposed allows the
HTTP server to tell the HTTP client two different things:
- The server has an https version of the origin available
- The https version of the origin is / is not expected to validate

My belief is that HTTP clients do not have enough communication with their
TLS stacks to be able to use the second piece of information in a secure
fashion; thus, it should be removed.

Your preference seems to be that we fix TLS so that a web site can offer
TLS in a way that a TLS client would not expect it to validate. That seems
fine, except then there also has to a way to communicate that to both the
HTTP client *and* the HTTP server. Do not assume that an HTTP server knows
the type of certificate and/or validation that is done.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 7 Oct 2013 15:25:08 -0700

> What are you including in that?

The non-zero probability of outright failure, the probability of
failure that looks like success, the extra round trips needed to some
types of requests, plus all the other things I'm not aware of around
use of Upgrade that causes things like websockets to fail.

> The biggest for me is perf, and that's pretty much a showstopper.

I have only the vaguest of inklings as to what you are talking about
here.  I'm not sure that others have even that much context.  I was
hoping that you could elaborate.

> Sorry, you're going to have to expand that a bit. What escape clause is too hand-wavey?

The "unless additional checks are performed" is the escape clause:

   Upon initial adoption of this proposal, it is expected that no such
   additional checks will be performed.  Therefore, the client MUST NOT
   use the "http2-tls-relaxed" profile to connect to alternate services
   whose host does not match that of the origin, unless additional
   checks are performed.

   This requirement bounds the risk of a service being hijacked and
   redirected to another host; see Security Considerations for details.

Note that using Upgrade provides a (marginally) stronger bound on this risk :)

> The server needs to know whether the cert is being validated (as discussed in a note near the end, there's more work to do on this).

I read through this draft several times, but didn't find a note that
explained it.  Even assuming Mike Bishop's inference, which is at
least superficially plausible, I don't see how that creates any
expectation that (thanks Paul) the server needs to know:

1) Whether or not the client authenticated [the server]
2) If (1) is true, whether there is a host name was in the cert's identity
3) If both (1) and (2) are true, what the host name is

If the intent is to learn what resources or origins a client might be
inclined to accept when pushed, then perhaps that needs to be explored
more.  The above is one of many solutions to that particular problem.
I suggest that foremost amoungst those solutions for consideration
should be "no protocol machinery".

---

From: Yoav Nir <[email-masked]>
Date: Mon, 7 Oct 2013 22:36:40 +0000

On Oct 7, 2013, at 8:00 PM, Paul Hoffman <[email-masked]> wrote:

> We're talking around the same problem. What Mark has proposed allows the HTTP server to tell the HTTP client two different things:
> My belief is that HTTP clients do not have enough communication with their TLS stacks to be able to use the second piece of information in a secure fashion; thus, it should be removed.

I don't think that is correct. In most browsers, when a server's certificate (chain) doesn't validate, you get some warning screen that allows you to click through. That means that the TLS stack informs the browser that validation failed, and the browser can tell the TLS stack to do it again, but ignore validation failures. Even cURL and wget have parameters that tell them to not validate certificate. So if a web client gets the second piece of information, it can tell the TLS layer to connect without validation, or it can try TLS with validation , and if that fails, the browser can tell the TLS layer to proceed without validation, even without showing a scary screen to the user.

> Your preference seems to be that we fix TLS so that a web site can offer TLS in a way that a TLS client would not expect it to validate. That seems fine, except then there also has to a way to communicate that to both the HTTP client *and* the HTTP server. Do not assume that an HTTP server knows the type of certificate and/or validation that is done.

A server without a certificate could still do ADH, and that gives us encrypted HTTP without all the PKI. If we install a certificate, we'd have to tell the HTTP server whether that certificate is going to validate or not.

---

From: Patrick McManus <[email-masked]>
Date: Mon, 7 Oct 2013 18:53:38 -0400

On Mon, Oct 7, 2013 at 6:36 PM, Yoav Nir <[email-masked]> wrote:

> > My belief is that HTTP clients do not have enough communication with
> their TLS stacks to be able to use the second piece of information in a
> secure fashion; thus, it should be removed.
>
> I don't think that is correct. In most browsers, when a server's
> certificate (chain) doesn't validate, you get some warning screen that
> allows you to click through. That means that the TLS stack informs the
> browser that validation failed, and the browser can tell the TLS stack to
> do it again, but ignore validation failures. Even cURL and wget have
> parameters that tell them to not validate certificate. So if a web client
> gets the second piece of information, it can tell the TLS layer to connect
> without validation, or it can try TLS with validation , and if that fails,
> the browser can tell the TLS layer to proceed without validation, even
> without showing a scary screen to the user.
>
> yoav is correct here.. browsers also have rather invasive things like
blacklists (e.g. diginotar) and might even enable features based on ciphers
or version levels. indeed http/2 demands >= TLS 1.1 :)

It's also true that the server can't know whether or not the client
performed validation; or if it did what set of CAs was used to do so or
whether revocation was checked and when, etc.... but that's equally true
today with https:// as it is with the proposed tls-relaxed. Presumably if
that was an important property to the server it wouldn't advertise them
both on the same port/npn identifier.

I strongly support the general notion of the draft, but that being said,
I'm not convinced we need to forgo validation just to do http:// over TLS.

-P

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 8 Oct 2013 19:47:24 +1300

> use of Upgrade that causes things like websockets to fail.

Yes.

> hoping that you could elaborate.

Upgrade would necessitate at least one extra RT, perhaps many; it's like STARTTLS. You'd be left with a useless connection while the connection upgraded. 

In contrast, the Alt-Svc approach would allow you to continue to use the existing non-TLS connection if you wanted to (acknowledging that some -- maybe many -- won't). 

More to the point, because the state of alternate services is cached across more than one connection, the impact is mitigated to only one connection per freshness lifetime period.

It's true that we could come up with some backwards-compatible caching scheme for Upgrade semantics, but IME retrofitting semantics onto existing fields is always nasty, and like you say, there are a lot of other problems. Fundamentally, using *another* connection is much more interesting than using *this* connection is. Upgrade only applies to this connection.

There's yet another motivation for Alt-Svc which I don't want to entwine in this discussion *too* much, since it's not a security requirement, and it's not fleshed out yet. 

HTTP/2 is introducing much longer-lived connections to the protocol, and that has significant impact on servers, load balancers and CDNs, who current rely on the short-lived session semantics of HTTP (often assisted by DNS trickery) to do their thing. The new abstraction of "alternate service" gives us a way to accommodate their needs to shift traffic around gracefully, while preserving the performance benefits of HTTP/2 (if we get it right).

All of that aside, an idea buried deep inside this draft is that the use of TLS is surfacing in the ALPN protocol now; how you discover it is a separable thing (and there may be many answers; e.g., Alt-Svc, Upgrade, DNS). The first question I'd like to see answered is whether people are comfortable with that.

>   redirected to another host; see Security Considerations for details.

Ah, that part. I know where you're coming from; this is really to start the discussion. AIUI some people feel that the hand-waviness is a good thing; hopefully that'll come out. OTOH if we can agree to tighten it up, I have absolutely no problem with that.

> explained it.  

Here you go:

"""
* Indicating Chosen Service: It's likely necessary for the server to know which
  protocol the client has chosen, and perhaps even the hostname (for load
  balancing). This could be conveyed as part of the "magic", or as a request
  header. There are also security implications here; for example, without this
  information, the server doesn't know if the client has checked the
  certificate, leading to a situation where an intermediary can downgrade a
  HTTPS connection to relaxed HTTP.
"""

This is the attack that Eliot highlighted earlier. I'm still not 100% convinced that this is significant, but it needs to be discussed.

> Even assuming Mike Bishop's inference, which is at

Imagine a server with both HTTPS URIs and HTTP URIs pointing at the same (host, port). 

I acknowledge that a suitable outcome might be "don't do that."

Back to the original question - as I alluded to in the draft, it may be that we don't need to define http2-tls-relaxed, because we can define the semantics of HTTP URIs using http2-tls with sufficient clarity.

Personally, I'm a big fan of being explicit, rather than relying on combinations of things ("http" uri + TLS profile) to infer things, especially when security is involved.

Additionally, I'm not yet convinced we're going to be able to agree on *one* way to do things here, which means we'll need a few different explicit options. I'd love to be proven wrong, of course.

In the meantime, feel free to read the http2-tls-relaxed section as "how we use http2-tls with HTTP URIs" if that makes it go down easier.

> more.  The above is one of many solutions to that particular problem.

To be honest, I hasn't considered the implications of push here; it is definitely an interesting (and necessary) avenue to explore.

> should be "no protocol machinery".

“Make things as simple as possible, but not simpler.”

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 8 Oct 2013 00:40:47 -0700

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 <[email-masked]> wrote:

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

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 8 Oct 2013 21:48:10 +1300

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

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 8 Oct 2013 13:26:25 -0700

On Tue, Oct 8, 2013 at 1:48 AM, Mark Nottingham <[email-masked]> wrote:

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

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?

> Yes, the draft talks about it, and I agree with your position:

Awesome. I agree with myself too.

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

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 08 Oct 2013 21:36:43 +0100

> HTTP/1.X connection warm and ready to go.)

I suspect the interesting questions to ask here relate to whether
or not that perf hit is needed to meet the security goals, and if
it is, then what to do about that.

Could be in this case, the kind of "turn on crypto after a delay"
approach you mention might be ok, but to know that, one would have
to carefully write down the security goals so you could check if
you're making a boo-boo or not.

Mark's draft is a good start at some of that, but clearly more is
needed.

S.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 8 Oct 2013 13:44:17 -0700

> it is, then what to do about that.

Yep, I was just trying to share our experience from Alternate-Protocol,
since it seemed relevant here. It's not clear to me how opportunistic we're
trying to be here in the security improvement, and how much we're willing
to pay the perf hit. I can tell you that before I implemented this racing
for Chromium, we definitely noticed the perf hit, which is why I
implemented it.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 8 Oct 2013 13:52:24 -0700

On 8 October 2013 13:44, William Chan (陈智昌) <[email-masked]> wrote:
> I can tell you that before I implemented this racing for Chromium, we
> definitely noticed the perf hit, which is why I implemented it.

I'd be interested in learning under what conditions a round trip
followed by the improved parallelism of HTTP/2 is still worse than
having to wait for new connections to be established in HTTP/1.1.  I
know that browsers tend to aggressively open multiple connections as
soon as they see a need for a connection to a host, but at some point
parallelism you are going to be paying round trips for connection
setup anyway.

Note also that we're talking about paying round trips to get TLS live
anyway.  So this IS going to hurt performance.  And, in many cases,
I'd have to assume that the security guarantees required for
/index.html are going to need to be higher than those around /foo.jpg.
 I don't want to get into a position where we secure just the
uninteresting stuff.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 8 Oct 2013 15:53:21 -0700

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 (陈智昌) <[email-masked]> wrote:
> 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 /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. 

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

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

> Awesome. I agree with myself too.

Good to know the universe is still well.

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

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 8 Oct 2013 18:26:16 -0700

> parallelism you are going to be paying round trips for connection

I'm not sure what details I'm able to provide, but speaking vaguely, a
vendor deployed SPDY by putting a reverse proxy in front of the normal
origin server and adding Alternate-Protocol. And then asked why it made
things slower. Upon analysis, we traced the cause to this mechanism. SPDY's
multiplexing improved the rest of the page load (and the next page
navigations), but the initial cold page load did suffer a hit.

>  I don't want to get into a position where we secure just the

I appreciate the comment and just want to emphasize that I am only sharing
previous experience with a similar method to the proposed I-D. My intent
was not to judge, but just to share information. It's not clear to me what
the exact goals of the I-D are, but I hope that the information I provided
can help guide discussion around the tradeoffs between performance and
security.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 8 Oct 2013 18:37:53 -0700

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

> > I don't understand this. Can you explain further? Just in case my
> problem description wasn't clear, let me restate:
> >
> > Cold page load
> 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.

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

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

> Good to know the universe is still well.

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

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 10 Oct 2013 11:28:18 -0700

If folks think that the discussion is leading away for a solution to the
problem of optimistic HTTP encryption due to it being too hard to start
from the HTTP headers, please do consider other options. A few years ago I
floated a proposal for a "HASTLS" DNS record that garnered some interest
but became bogged down in policy questions relating to fallback from secure
to insecure. (The abandoned draft is at
http://tools.ietf.org/html/draft-hoffman-server-has-tls-05) I could revive
that draft, stripped of the fallback language, if this WG wants optimistic
HTTP but can't see a good way to get it in HTTP itself.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 14 Oct 2013 11:24:38 -0700

I went ahead and jotted down some notes into a draft that might help
clarify what I am thinking about for making optimistic TLS notifications in
DNS instead of HTTP headers. If people like this idea, I'll pursue it; if
not, I'm happy to let it die.

--Paul Hoffman

Filename:     draft-hoffman-trytls
Revision:     00
Title:         Optimistic Encryption using TLS Signaling in the DNS
Creation date:     2013-10-14
Group:         Individual Submission
Number of pages: 4
URL:
http://www.ietf.org/internet-drafts/draft-hoffman-trytls-00.txt
Status:          http://datatracker.ietf.org/doc/draft-hoffman-trytls
Htmlized:        http://tools.ietf.org/html/draft-hoffman-trytls-00

Abstract:
  Many Internet servers offer content in two transports: unencryped,
  and encrypted with TLS.  A user who accesses some content with a URL
  that indicates unencrypted (such as "http:") might prefer to get the
  content encrypted but doesn't bother to change the URL to indicate
  this.  This proposal allows Internet clients, particularly web
  clients and mail user agents, to do a DNS lookup to see whether they
  might expect content for a particular host to also be available under
  TLS.  Using the DNS for this is much faster than attempting a TLS
  session that might time out or take many round trips in order to
  discover that the content is not available.

On Thu, Oct 10, 2013 at 11:28 AM, Paul Hoffman <[email-masked]>wrote:

> http://tools.ietf.org/html/draft-hoffman-server-has-tls-05) I could
> revive that draft, stripped of the fallback language, if this WG wants
> optimistic HTTP but can't see a good way to get it in HTTP itself.
>
> --Paul Hoffman
>