Subject: A proposal

From: James M Snell <[email-masked]>
Date: Sun, 17 Nov 2013 10:08:04 -0800

The volume on the other threads on the security subject is causing far too
much noise. I have a proposal that offers a compromise approach. I posted
about this partially in one of the threads but I'm afraid it got lost in
the noise. Others have touched on the same basic idea:

1. By default, assign plain text http/2 to a new port.
2. Document that plaintext http/2 can be sent over port 80 but document the
various possible issues with reliability.
3. Strongly recommend that http/2 be sent over TLS instead of plaintext.
4. Establish a new http2 URL protocol prefix for plaintext http2 over the
new default port

This does several things.

A. It makes plaintext http/2 possible but significantly harder. Some. Would
argue that makes plaintext http/2 "undeployable"... The same people who
have argued that have also argued that plaintext http/2 should not be used
at all. Therefore, those people really do not lose anything by following
this approach.

B. It makes http/2 over TLS the default for the public internet since
that's the only option that would be broadly deployable on today's
infrastructure.

C. It makes it less likely that we would have to deal with the upgrade
dance on port 80. Which is a good thing. Http:// URLs would always mean
http/1.x. Http2://example:80 would mean http/2 over port 80.

D. Developers would be forced to make a conscious choice to use plaintext
http/2 over an established default port. There's zero ambiguity.

The folks who are arguing for TLS only really lose nothing with this
approach. It still, over course, does nothing about the mitm issues on port
443, but its a start.

- James

---

From: Roland Zink <[email-masked]>
Date: Sun, 17 Nov 2013 19:12:20 +0100

+1
On 17.11.2013 19:08, James M Snell wrote:
>
> The volume on the other threads on the security subject is causing far 
> too much noise. I have a proposal that offers a compromise approach. I 
> posted about this partially in one of the threads but I'm afraid it 
> got lost in the noise. Others have touched on the same basic idea:
>
> 2. Document that plaintext http/2 can be sent over port 80 but 
> document the various possible issues with reliability.
> 4. Establish a new http2 URL protocol prefix for plaintext http2 over 
> the new default port
>
> A. It makes plaintext http/2 possible but significantly harder. Some. 
> Would argue that makes plaintext http/2 "undeployable"... The same 
> people who have argued that have also argued that plaintext http/2 
> should not be used at all. Therefore, those people really do not lose 
> anything by following this approach.
>
> dance on port 80. Which is a good thing. Http:// URLs would always 
> mean http/1.x. Http2://example:80 would mean http/2 over port 80.
>
> D. Developers would be forced to make a conscious choice to use 
> plaintext http/2 over an established default port. There's zero ambiguity.
>
> approach. It still, over course, does nothing about the mitm issues on 
> port 443, but its a start.
>
> - James
>

---

From: James M Snell <[email-masked]>
Date: Sun, 17 Nov 2013 10:20:32 -0800

Ugh..  Sorry for the autocorrect errors in that post.  Typing email on
tablets is still a rather sub par experience.
On Nov 17, 2013 10:08 AM, "James M Snell" <[email-masked]> wrote:

> 2. Document that plaintext http/2 can be sent over port 80 but document
> the various possible issues with reliability.
> Would argue that makes plaintext http/2 "undeployable"... The same people
> who have argued that have also argued that plaintext http/2 should not be
> used at all. Therefore, those people really do not lose anything by
> following this approach.
>

---

From: Zhong Yu <[email-masked]>
Date: Sun, 17 Nov 2013 12:53:03 -0600

As a web page author, how do I choose which scheme, http:// or
http2://, to use for a link? Do I need to detect the browser version
the page is rendered on?

On Sun, Nov 17, 2013 at 12:08 PM, James M Snell <[email-masked]> wrote:
> about this partially in one of the threads but I'm afraid it got lost in the
> noise. Others have touched on the same basic idea:
>
> argue that makes plaintext http/2 "undeployable"... The same people who have
> argued that have also argued that plaintext http/2 should not be used at
> all. Therefore, those people really do not lose anything by following this
> approach.
>
> B. It makes http/2 over TLS the default for the public internet since that's
> the only option that would be broadly deployable on today's infrastructure.
>
> C. It makes it less likely that we would have to deal with the upgrade dance
> on port 80. Which is a good thing. Http:// URLs would always mean http/1.x.
> Http2://example:80 would mean http/2 over port 80.
>

---

From: James M Snell <[email-masked]>
Date: Sun, 17 Nov 2013 11:00:00 -0800

If you choose to deploy plaintext http/2 for your server,  and you want
people to use that,  then use http2://. Detection of browser capability to
handle http2 links is orthogonal.  If you want a better, more reliable,
more seamless experience,  use  http2 over TLS.

The idea here is to purposefully not solve all of the possible issues with
plaintext http/2. Rather,  we make plaintext http/2 possible for those
willing to put up with the extra pain while optimizing only for the secure
path.
 On Nov 17, 2013 10:53 AM, "Zhong Yu" <[email-masked]> wrote:

> too
> the
> the
> Would
> have
> that's
> dance

---

From: Patrick McManus <[email-masked]>
Date: Sun, 17 Nov 2013 14:34:43 -0500

On Sun, Nov 17, 2013 at 1:08 PM, James M Snell <[email-masked]> wrote:

> I will not deploy another cleartext protocol. Especially another one where
the choice of encryption is solely made by the server. It doesn't serve my
user base, or imo the web.

-P

---

From: James M Snell <[email-masked]>
Date: Sun, 17 Nov 2013 11:40:26 -0800

Then don't.  This approach does not require you to do anything you don't
want to do.  It just says that if you want plaintext http/2 you can have
it. On a different default port and a few other moderately difficult
hurdles.  If,  however,  you want to deploy on the open Web,  the secure
approach is more reliable and less painful and is likely what you should do
instead.
 On Nov 17, 2013 11:34 AM, "Patrick McManus" <[email-masked]> wrote:

>> posted about this partially in one of the threads but I'm afraid it got
>> lost in the noise. Others have touched on the same basic idea:
>>
>> I will not deploy another cleartext protocol. Especially another one
> where the choice of encryption is solely made by the server. It doesn't
> serve my user base, or imo the web.
>
> -P
>
>
>
>>
>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 17 Nov 2013 19:58:46 +0000

>http2://, to use for a link? Do I need to detect the browser version

Right now we have two schemes in common use:  "http" and "https"
and people in both ends of the HTTP connection interpret that 
(more or less) as "without privacy" and "with privacy" respectively.

This is counter to the IETFs ratified semantics of the scheme as
protocol selector for these two values, but I think we will shoot
ourselves big holes in the feet, if we try to press the IETF
view down over everybodys head, as a preconditition for using HTTP2.

The choice of HTTP/1 vs. HTTP/2 should be decoupled from the HTML
and from the browsers URL field, and therefore I cannot support
James proposal.

My counter proposal:

1. HTTP/2 on port 100 is always plaintext, which makes life easy
   for network people and is conceptually simple for everybody
   to understand.  It also does not need any RTT before HTTP/2
   performance benefits kick in.

2. Encrypted HTTP/2 will go over 443 (if SSL/TLS is used, otherwise
   I suspect that will need a new port too ?)  This makes life
   easy and is conceptually easy to understand too.

3. Servers or intermediaries which can do HTTP/2 (port 100 and/or
   443) can indicate this two ways:

   a) By sending a header in only the *first* HTTP/1 response on
      any connection.

      This new header must be listed in "Connection:" since protocols
      supported is by nature a hop-by-hop property.

      (For further study:  Make this a general purpose header which
      can also indicate HTTPS, SCTP or other protols supported ?)

   b) In DNS records. (For futher study:  How ?)

   Servers should do both. Intermediaries can only do a).

4. URIs in HTML documents do not change.

	"http:" means "no privacy needed"
	"https:" means "privacy required"

   The user-agent gets to resolve that into HTTP/1 and HTTP/2 (or
   any other protocols), according to policy, preference and custom,
   based on server provided information, possibly cached.

5. Upgrading a HTTP/1 connection on port 80 to HTTP/2 will not
   be supported, the risk of reducing web relibility is too high and
   it would add RTT costs before HTTP/2 performance benefits kick in.

6. Upgrading a HTTP/1 connection on port 443 to HTTP/2 is desired
   only if HTTP/2 cannot be a negotiated option during the TLS -
   handshake.  I don't know the answer to this one, it may for
   further study ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Karl Dubost <[email-masked]>
Date: Sun, 17 Nov 2013 14:59:53 -0500

(If I understood the initial proposal.)

Le 17 nov. 2013 à 14:40, James M Snell <[email-masked]> a écrit :
> Then don't.  This approach does not require you to do anything you don't want to do.  It just says that if you want plaintext http/2 you can have it.

Site A (http2-enc) is making a link to site B (http2-plain). How the author of site A is supposed to know that site B is using a different HTTP scheme?

So the new list of URIs schemes will be (according to the proposal)

http://  -> http 1.1 (plain text)
https:// -> http 1.1 (secure)
http://  -> http 2.0 (secure)
http2:// -> http 2.0 (plain text)

Is it that? I can see on the author side more headaches. Or we effectively give up on http and write things like <a href="//example.org/foo">blah</a> (which might be a good idea).

-- 
Karl Dubost
http://www.la-grange.net/karl/

---

From: Zhong Yu <[email-masked]>
Date: Sun, 17 Nov 2013 14:05:16 -0600

A new scheme is too disruptive, we need to think through all the
implications before taking it as a viable solution for clear http2.

I like the idea of a new port. But I'd rather keep the old "http"
scheme - it gives a tiny systematic bias to the old port, but the bias
is probably insignificant in the thought process of choosing a port
for clear http2. A service provider most likely goes with whichever
port that's more reliable today. We don't care which port wins the
evolution race. If the new ports turns out to be useless, and port 80
works just fine, so be it.

BTW, is port 02 really used by anyone? Wouldn't it be cool to assign
it to http2? So we can have URLs like

    http://example.com:2/foo

On Sun, Nov 17, 2013 at 1:00 PM, James M Snell <[email-masked]> wrote:
> handle http2 links is orthogonal.  If you want a better, more reliable, more
> seamless experience,  use  http2 over TLS.
>
>> > plaintext

---

From: Zhong Yu <[email-masked]>
Date: Sun, 17 Nov 2013 14:15:46 -0600

If a URL is http://something, it better means that the document can be
retrieved by HTTP/1 on clear TCP. If that assumption is broken, a lot
of software will be broken.

---

From: Mike Belshe <[email-masked]>
Date: Sun, 17 Nov 2013 12:32:06 -0800

I think I replied earlier, but I am strongly against any proposal which
introduces new URL scheme for HTTP.

This is changing the UI of the web, which most users don't understand (and
shouldn't need to).  Right now, users don't have to know about HTTP2 vs
HTTP1.1 vs HTTP1.  If we make them have to differentiate, we've really
screwed up badly.

This would also open a new set of security risks, as you'd now have to deal
with sites that include resources from http: and http2:, and is that a
mixed-content warning?  I think it would have to be.

Finally, this would make server side deployment very hard - there are a
tremendous number of applications (php, java, etc) with 'http://' hard
coded, and all of those would have to change.

Mike

On Sun, Nov 17, 2013 at 12:15 PM, Zhong Yu <[email-masked]> wrote:

> > In message <
> [email-masked]>
> > , Zhong Yu writes:
> >

---

From: Tim Bray <[email-masked]>
Date: Sun, 17 Nov 2013 12:45:19 -0800

Yeah, Mike’s right; the proposal is architecturally cool, I like it; but
the universe of Web content is completely permeated with hardcoded “http://”
and “https://” (static files, code, and templates) and I think we have to
live with that :(

On Sun, Nov 17, 2013 at 12:32 PM, Mike Belshe <[email-masked]> wrote:

> This would also open a new set of security risks, as you'd now have to
> deal with sites that include resources from http: and http2:, and is that a

---

From: "Adrien de Croy" <[email-masked]>
Date: Sun, 17 Nov 2013 20:47:34 +0000

compared with the existing proposed methods of determining whether 
http/2.0 is available or not, including:

* some new DNS record
* upgrade dance

actually testing for connectivity on a new port is miles easier. A 
client can send 2 SYN packets at the same time.  Connectivity on a new 
reserved/allocated port such as 100 would be a fairly clear indication 
that we are dealing with http/2.0

Keep in mind, with a MITM, you can't presume that http/2.0 is deployable 
as currently proposed over 443 with NPN or ALPN.  In fact I believe that 
due to the growth of MITM, the deployabilty of anything other than 
http/1.1 over TLS is reducing.

Crypto or not could then be negotiated on the connection.  A server can 
offer it, and a client can defer to a user as to whether the user is 
prepared to go unencrypted or not.  Agents so configured can make that 
choice already, so that plaintext deployment is possible with low pain 
level in situations that require it.

No need or desire for a new scheme (and face it, no-one is going to 
re-write their web apps for a new scheme to send people down the garden 
path by advertising a new scheme which the client cannot access).

Adrien

---

From: James M Snell <[email-masked]>
Date: Sun, 17 Nov 2013 12:57:40 -0800

This proposal doesn't change that assumption.  It just says that if you see
http:// that means http/1.x. If you see https, that means TLS with either
http/1.x or 2.0. You only get plain text http/2 if you use the new scheme.
That ought to sufficiently make plain text http/2 largely undependable on
the broader Web,  while still allowing those who really want it a means of
doing so.

If someone wants to use a response header or DNS or whatever to advertise
that they support plaintext http/2, then they may do so.  But that's an
orthogonal issue.
 On Nov 17, 2013 12:45 PM, "Tim Bray" <[email-masked]> wrote:

>> This is changing the UI of the web, which most users don't understand
>> (and shouldn't need to).  Right now, users don't have to know about HTTP2
>> vs HTTP1.1 vs HTTP1.  If we make them have to differentiate, we've really
>> screwed up badly.
>>

---

From: Roberto Peon <[email-masked]>
Date: Sun, 17 Nov 2013 13:01:13 -0800

Folks won't rewrite for a new scheme until it is supported by all clients,
and that won't happen until there is sufficient (and by that I mean
overwhelming) demand for such.
... thus, a new scheme won't work as it is firmly in
chicken-and-egg territory, even in intranets :/

Happy eyeballs-like strategies either introduce latency or introduce
complexity, and sometimes both. For fun: which connection do you send any
particular request down?

HTTP/2 over :443 works just fine even with MITMs, as they will need to
terminate the TLS channel, which means that they can refuse to negotiate
HTTP/2 during the ALPN negotiation.

-=R

On Sun, Nov 17, 2013 at 12:47 PM, Adrien de Croy <[email-masked]> wrote:

> actually testing for connectivity on a new port is miles easier. A client
> can send 2 SYN packets at the same time.  Connectivity on a new
> reserved/allocated port such as 100 would be a fairly clear indication that
> we are dealing with http/2.0
>
> due to the growth of MITM, the deployabilty of anything other than http/1.1
> over TLS is reducing.
>

---

From: "Adrien de Croy" <[email-masked]>
Date: Sun, 17 Nov 2013 21:05:29 +0000

Hi

------ Original Message ------
From: "Roberto Peon" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "James M Snell" <[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 18/11/2013 10:01:13 a.m.
Subject: Re: A proposal
>Folks won't rewrite for a new scheme until it is supported by all 
>clients, and that won't happen until there is sufficient (and by that I 
>mean overwhelming) demand for such.
>... thus, a new scheme won't work as it is firmly in chicken-and-egg 
>territory, even in intranets :/
that's basically what I was saying. I don't think a new scheme will 
work, and I don't think we need one.

>complexity, and sometimes both. For fun: which connection do you send 
>any particular request down?
Chrome already makes many opportunistic connections that never get a 
request.

how woudl making some over 100 be any different.
If you get a connection on both, use port 100 for http/2.0 and drop the 
80 one, and remember that.

We could also use DNS (e.g. new record, or new SRV record) to make this 
more deterministic.

>terminate the TLS channel, which means that they can refuse to 
>negotiate HTTP/2 during the ALPN negotiation.

Yes.  I'm saying the more MITMs go out there that don't support 2.0, the 
less likely you will get 2.0.  It will be down-graded to 1.1 over TLS.  
So claims about deployability of 2.0 over 443 I think should not just be 
swallowed without question.

Adrien

>>Keep in mind, with a MITM, you can't presume that http/2.0 is 
>>deployable as currently proposed over 443 with NPN or ALPN.  In fact I 
>>believe that due to the growth of MITM, the deployabilty of anything 
>>other than http/1.1 over TLS is reducing.
>>
>>Crypto or not could then be negotiated on the connection.  A server 
>>can offer it, and a client can defer to a user as to whether the user 
>>is prepared to go unencrypted or not.  Agents so configured can make 
>>that choice already, so that plaintext deployment is possible with low 
>>pain level in situations that require it.
>>
>>re-write their web apps for a new scheme to send people down the 
>>garden path by advertising a new scheme which the client cannot 
>>access).
>>
>>Adrien
>>
>>
>>>The volume on the other threads on the security subject is causing 
>>>far too much noise. I have a proposal that offers a compromise 
>>>approach. I posted about this partially in one of the threads but I'm 
>>>afraid it got lost in the noise. Others have touched on the same 
>>>basic idea:
>>>
>>>C. It makes it less likely that we would have to deal with the 
>>>upgrade dance on port 80. Which is a good thing. Http:// URLs would 
>>>always mean http/1.x. Http2://example:80 would mean http/2 over port 
>>>80.
>>>
>>>approach. It still, over course, does nothing about the mitm issues 
>>>on port 443, but its a start.
>>>
>>>- James
>>>
>>>
>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 17 Nov 2013 21:09:53 +0000

>of software will be broken.

No, it means "fetch this with HTTP", it doesn't say "HTTP/1" anywhere
and if the user-agent determines that it can be fetched better with
HTTP/2 on port 100, then that's just fine.

Now, if a port number is specified, things get more hairy, and that
could be documented as a way to insist on a particular HTTP version
if my proposal is adopted.

Poul-Henning

---

From: Zhong Yu <[email-masked]>
Date: Sun, 17 Nov 2013 15:17:46 -0600

> the broader Web,  while still allowing those who really want it a means of

I'm confused - is it your objective to make plain http2 more
undependable on the broader web? Since your wording sounds like that.

>>> (and shouldn't need to).  Right now, users don't have to know about HTTP2 vs
>>>> > In message
>>>> > <[email-masked]>
>>>> > , Zhong Yu writes:
>>>> >

---

From: James M Snell <[email-masked]>
Date: Sun, 17 Nov 2013 13:19:59 -0800

The proposal is to make it possible but with additional steps.  As opposed
to the other proposal that says no plaintext http/2 at all.
On Nov 17, 2013 1:17 PM, "Zhong Yu" <[email-masked]> wrote:

> >>>> On Sun, Nov 17, 2013 at 1:58 PM, Poul-Henning Kamp <
> [email-masked]>
> >>>> wrote:
> >>>> > In message
> >>>> > <[email-masked]
> >
> >>>> > , Zhong Yu writes:
> >>>> >

---

From: Zhong Yu <[email-masked]>
Date: Sun, 17 Nov 2013 15:22:09 -0600

> HTTP/2 on port 100, then that's just fine.

There are a lot of existing programs, other than the few leading
browsers, that interpret "http://" URLs that way. Your proposal will
break them.

---

From: James M Snell <[email-masked]>
Date: Sun, 17 Nov 2013 13:22:11 -0800

For those for whom plain text http/2 is important,  it will be
implemented.  For those who don't care,  they won't bother.  If it becomes
important enough,  the tooling will emerge.

---

From: Zhong Yu <[email-masked]>
Date: Sun, 17 Nov 2013 15:27:10 -0600

The current spec already allows plain http2. What does your proposal
try to achieve? My impression was that you want to make it more
reliable on open web. But later you sounded like you want to make it
less reliable. (In no way I'm trying to question your intention; this
thing is too complicated and we are all lost in words)

On Sun, Nov 17, 2013 at 3:19 PM, James M Snell <[email-masked]> wrote:
>> >>>> On Sun, Nov 17, 2013 at 1:58 PM, Poul-Henning Kamp
>> >>>> <[email-masked]>
>> >>>> wrote:
>> >>>> > In message
>> >>>> >

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 17 Nov 2013 21:31:10 +0000

>browsers, that interpret "http://" URLs that way. Your proposal will

Nope, it will work just fine.

If the user-agent doesn't know about HTTP/2, it will use HTTP/1 just
like always.

If it knows about HTTP/2 and can fetch the content with HTTP/2 because
the upstream indicated this, it will just work.

If it cannot fetch it with HTTP/2, despite upstream indication (firewall
etc.) It will fall back to HTTP/1 and maybe cache this info for some
amount of time to save time.

The only thing my proposal does not allow you to do, is deploy an
HTTP/2 only site, but given how few IPv6 only sites there are, I
don't think that is going to be a problem for anybody.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 17 Nov 2013 21:40:12 +0000

In message <CACuKZqHj8zS1-FTDzUeVrt39a7Moojw3eVciHW5fTaf=[email-masked]>
, Zhong Yu writes:

>try to achieve?

Mainly it tried to get us back to talk about the HTTP/2 protocol
design, rather than waste time trying to pull out the nail policiticians
pouned in, with our screwdriver.

---

From: James M Snell <[email-masked]>
Date: Sun, 17 Nov 2013 13:44:19 -0800

It intentionally pushes people towards https in the default most common
cases while making it still possible to do plaintext...
On Nov 17, 2013 1:27 PM, "Zhong Yu" <[email-masked]> wrote:

> >> > This proposal doesn't change that assumption.  It just says that if
> you
> >> > see
> >> > the broader Web,  while still allowing those who really want it a
> means
> >> > of
> >> > doing so.
> >>
> >> >> and “https://” (static files, code, and templates) and I think we
> have
> >> >> to
> >> >> live with that :(
> >> >>
> >> >>
> >> >>> Finally, this would make server side deployment very hard - there
> are
> >> >>> a
> >> >>>> If a URL is http://something, it better means that the document
> can
> >> >>>> be
> >> >>>> > <

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 17 Nov 2013 21:50:32 +0000

In message <CABP7Rbetp3r181ZXTUW9s-kg=mn=zK93oeHW=[email-masked]>

>cases while making it still possible to do plaintext...

If you want to do that, you should do it through open advocacy,
not by changing almost 20 years of established practice with
little notice.

---

From: Zhong Yu <[email-masked]>
Date: Sun, 17 Nov 2013 15:51:12 -0600

So it's a sin tax:) There are two problems:
1. people who want plaintext http2 do not think it is a sin.
2. the tax is too high which practically outlaws plaintext http2.

On Sun, Nov 17, 2013 at 3:44 PM, James M Snell <[email-masked]> wrote:
>> >> > That ought to sufficiently make plain text http/2 largely
>> >> > undependable
>> >> > on
>> >> >>> deal with sites that include resources from http: and http2:, and
>> >> >>> is
>> >> >>> that a
>> >> >>>> >    it would add RTT costs before HTTP/2 performance benefits
>> >> >>>> > kick
>> >> >>>> > in.
>> >> >>>> >

---

From: "Adrien de Croy" <[email-masked]>
Date: Sun, 17 Nov 2013 21:52:46 +0000

as a web site operator and web user, I don't want to be pushed towards 
https and have life made more difficult to remain plaintext.  That 
overall will just make my life more difficult.

I want to be able to leave it as is.  It would be nice to know if my 
https is being intercepted, but if I'm worried, I can check the cert.  
Something more deterministic would be better so I didn't have to look, 
since it's a pain to drill into the cert.

There's another aspect we haven't discussed either.

Client side caches don't just free up client side resources - they also 
save server resources.  A client that doesn't have to make another 
request, saves the server from dealing with it.

So, compulsory (or heavily skewed towards) crypto by introducing pain 
into the plaintext option will increase server requirements for more 
reasons than just the crypto CPU burden which we already have a problem 
with.  There will also be an increase in requests due to reduced 
cachability (e.g. in intermediary caches).

Adrien

------ Original Message ------
From: "James M Snell" <[email-masked]>
To: "Zhong Yu" <[email-masked]>
Cc: "Tim Bray" <[email-masked]>; "[email-masked]" 
<[email-masked]>; "Poul-Henning Kamp" <[email-masked]>; "Mike 
Belshe" <[email-masked]>
Sent: 18/11/2013 10:44:19 a.m.
Subject: Re: A proposal
>> >> > This proposal doesn't change that assumption.  It just says that 
>>if you
>> >> > see
>> >> > http:// that means http/1.x. If you see https, that means TLS 
>>with
>> >> > either
>> >> > http/1.x or 2.0. You only get plain text http/2 if you use the 
>>new
>> >> > scheme.
>> >> >> Yeah, Mike’s right; the proposal is architecturally cool, I like 
>>it;
>> >> >> but
>> >> >> the universe of Web content is completely permeated with 
>>hardcoded
>> >> >> “http://”
>> >> >> and “https://” (static files, code, and templates) and I think 
>>we have
>> >> >> to
>> >> >> live with that :(
>> >> >>
>> >> >>
>> >> >>> I think I replied earlier, but I am strongly against any 
>>proposal
>> >> >>> which
>> >> >>> (and shouldn't need to).  Right now, users don't have to know 
>>about
>> >> >>> HTTP2 vs
>> >> >>> deal with sites that include resources from http: and http2:, 
>>and is
>> >> >>> that a
>> >> >>> Finally, this would make server side deployment very hard - 
>>there are
>> >> >>> a
>> >> >>> On Sun, Nov 17, 2013 at 12:15 PM, Zhong Yu 
>><[email-masked]>
>> >> >>> wrote:
>> >> >>>>
>> >> >>>> If a URL is http://something, it better means that the 
>>document can
>> >> >>>> be
>><mailto:[email-masked]>
>> >> >>>> > , Zhong Yu writes:
>> >> >>>> >
>> >> >>>> > view down over everybodys head, as a preconditition for 
>>using
>> >> >>>> > HTTP2.
>> >> >>>> >
>> >> >>>> >    be supported, the risk of reducing web relibility is too 
>>high
>> >> >>>> > and
>> >> >>>> > Never attribute to malice what can adequately be explained 
>>by
>> >> >>>> > incompetence.
>> >> >>>>
>> >> >>>
>> >> >>
>> >> >

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 17 Nov 2013 15:27:17 -0800

> HTTP/2 on port 100, then that's just fine.

The URI scheme defines a name resolution mapping.  "http", in particular,
defines a mapping to a hypothetical HTTP server listening to the default
(or given) TCP port.  That server is authoritative for the remaining URI
bits.

The scheme does not mean "fetch"; GET does, which is a method constructed
based on context found outside the URI.

The scheme does not mean "use HTTP"; the tools a user chooses to make
use of the Internet determine what protocols to use, corresponding to
which schemes, and may or may not intend to do so through network access
to an authoritative server.  "http" URIs can and do "work" when a user
agent has no network access.

Security is a systemic issue, not a protocol issue.  There is nothing
secure about TLS or encryption.  There are merely some use cases in
which the data crossing the wire can be made confidential to a given
set of key holders, preferably controlled by the entity to which the
user intends to communicate in confidence.  That level of confidentiality
is sufficient for many commerce use cases.  It does not provide privacy.

Anyone who thinks adding TLS to plain HTTP will improve security,
let alone privacy, needs to learn how TLS gets its security.
Encryption is not magic pixie dust.

For HTTP, the scheme identifies an authority. A user trusts their
user agent to retrieve somewhat authoritative responses. If a user
agent can obtain reasonably authoritative responses via other
means, then it can use those other means instead of the default
means defined by the scheme, regardless of the scheme.

....Roy

---

From: Mike Belshe <[email-masked]>
Date: Sun, 17 Nov 2013 15:40:05 -0800

On Sun, Nov 17, 2013 at 3:27 PM, Roy T. Fielding <[email-masked]> wrote:

> > In message <CACuKZqHKjpvgu=
> [email-masked]>
> > , Zhong Yu writes:
> >

So your official statement is that TLS does not improve the security or
privacy of HTTP?

Mike

---

From: Michael Sweet <[email-masked]>
Date: Sun, 17 Nov 2013 21:26:55 -0500

James,

I'm generally -1 on this approach, and I really don't like introducing a new URI scheme - we end up partitioning the 'web and make it confusing to deploy (how do you explain why https: doesn't need the same treatment and http: still works, etc.)

I personally think we can make the 2.0 upgrade on http: work over port 80 more reliably with broken proxies, but we really need to do more testing to actually know whether delaying the upgrade until the client sees an Upgrade: header from the server helps (the first request is HTTP/1.1, then the following request starts the upgrade...)

On Nov 17, 2013, at 1:08 PM, James M Snell <[email-masked]> wrote:

> The volume on the other threads on the security subject is causing far too much noise. I have a proposal that offers a compromise approach. I posted about this partially in one of the threads but I'm afraid it got lost in the noise. Others have touched on the same basic idea:
> 
> 2. Document that plaintext http/2 can be sent over port 80 but document the various possible issues with reliability.
> 4. Establish a new http2 URL protocol prefix for plaintext http2 over the new default port
> 
> A. It makes plaintext http/2 possible but significantly harder. Some. Would argue that makes plaintext http/2 "undeployable"... The same people who have argued that have also argued that plaintext http/2 should not be used at all. Therefore, those people really do not lose anything by following this approach.
> 
> B. It makes http/2 over TLS the default for the public internet since that's the only option that would be broadly deployable on today's infrastructure.
> 
> C. It makes it less likely that we would have to deal with the upgrade dance on port 80. Which is a good thing. Http:// URLs would always mean http/1.x. Http2://example:80 would mean http/2 over port 80.
> 
> D. Developers would be forced to make a conscious choice to use plaintext http/2 over an established default port. There's zero ambiguity.
> 
> The folks who are arguing for TLS only really lose nothing with this approach. It still, over course, does nothing about the mitm issues on port 443, but its a start. 
> 
> - James
> 
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Nov 2013 13:48:47 +1100

FWIW - James has brought this idea to the WG in the past, and we've failed to get any consensus on it. I don't see it gaining any more now.

Regards,

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

---

From: James M Snell <[email-masked]>
Date: Sun, 17 Nov 2013 19:09:31 -0800

Well,  from what I've seen in this thread so far, only the idea of a new
url scheme seems unpopular.  The idea of having a dedicated port for
plaintext http/2 has received several mentions of support. Nevertheless,
the proposal was relevant to the conversation so I brought it up again.
Definitely seems like positions haven't changed so I'll go ahead and not
mention it again.
On Nov 17, 2013 6:48 PM, "Mark Nottingham" <[email-masked]> wrote:

> FWIW - James has brought this idea to the WG in the past, and we've failed
> to get any consensus on it. I don't see it gaining any more now.
>
> Regards,
>
>
> > I'm generally -1 on this approach, and I really don't like introducing a
> new URI scheme - we end up partitioning the 'web and make it confusing to
> deploy (how do you explain why https: doesn't need the same treatment and
> http: still works, etc.)
> >
> > I personally think we can make the 2.0 upgrade on http: work over port
> 80 more reliably with broken proxies, but we really need to do more testing
> to actually know whether delaying the upgrade until the client sees an
> Upgrade: header from the server helps (the first request is HTTP/1.1, then
> the following request starts the upgrade...)
> >
> >

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Nov 2013 14:11:31 +1100

On 18/11/2013, at 2:09 PM, James M Snell <[email-masked]> wrote:

> Well,  from what I've seen in this thread so far, only the idea of a new url scheme seems unpopular.  The idea of having a dedicated port for plaintext http/2 has received several mentions of support. Nevertheless,  the proposal was relevant to the conversation so I brought it up again.  Definitely seems like positions haven't changed so I'll go ahead and not mention it again.

Yep, a new port hasn't been ruled out, and there's been some interest in the past. 

Personally, I suspect that *if* we have a mechanism to direct a connection to anther host or port (whether that's Alt-Svc or something completely different), it might make sense to define a default port for it, to make firewalls' jobs easier.

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Nov 2013 14:12:32 +1100

Hi PHK,

So, this is effectively a proposal of how to upgrade plaintext HTTP/1 to HTTP/2. It has some interesting properties, and similar things have been mentioned in the past. Personally, I think a separate port for unencrypted HTTP/2 is interesting.

However, the question at hand is whether and when HTTP/2 will be *used* for HTTP URLs, not the specifics of the upgrade mechanism. We've had plenty of discussion about that, and I encourage you to familiarise yourself with where we've been on that (much of your proposal overlaps with or is compatible with previous discussion on the topic).

To be clear -- the current draft says NOTHING to constrain http:// URLs in the draft; this means that the status quo is that implementations select what conditions they implement HTTP/2 under. We have at least two browsers that have clearly indicated they will only do so for https:// URLs, and significant support for that position from others.

I can see two possible paths forward:

* We can continue to say nothing, meaning that at least some implementations will only implement HTTP/2 for https:// URIs, and interop will be determined by the market (read: chaotic). If we keep on spinning our wheels, this is likely where we'll end up; we can't let this issue dominate the rest of our work.

* We can compromise and agree upon when and where HTTP/2 can be used for http:// URLs (e.g., for .local and RFC1918 addresses, and/or when alternate mechanisms for important aspects of security are layered in, whether that's opportunistic encryption or something else). This is where I think more discussion will help.

If anyone can suggest another realistic approach, we're listening.

Again, the relevant issue:
  https://github.com/http2/http2-spec/issues/314

Cheers,

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 18 Nov 2013 08:43:11 +0000

In message <[email-masked]>, Mark Nottingham wri
tes:

>So, this is effectively a proposal of how to upgrade plaintext HTTP/1 to 
>HTTP/2.

You can call it that, I saw it more as an attempt to call the party
to order and get back to business :-)

I thought, and that's probably just me being naiive, that our business
was something like:

	1. Design a HTTP/2.0 protocol which has awesome performance
	   and does what people need, making it an obviously desirable
	   upgrade.

	2. Define how it can be deployed in a smooth fashion, with
	   no havoc and minimum pain.

	3. Spend more time with the family.

My assumption with respect to item 2 was that we would aim for
something which required no effort outside the transport function,
ideally just:

	1. Upgrade your webserver/proxy/browser software
	(2. Punch missing hole in firewall)
	3. Profit!

And therefore it came as a total surprise for me, that people would
even consider adding a new URI scheme as part of HTTP/2.

That would for instance require CMS designers to change their code
so they can deliver old-style URIs to HTTP/1 clients (which would
not know what to do about the new ones) and new-style URIs for HTTP/2.

(And what to do about all the old content, do you need to go through
that and change the URIs ?)

I think it might be a timesaver to decide questions like this up
front, since it has pretty big architectural impact down the road,
and if we want to add URI schemes, we should alert the CMS people
at the earliest possible moment.

If SPDY is what we're going to goldplate into HTTP/2, I think my
proposal is basically sound, but it was hashed out in a matter of
minutes and there are som interesting corners, such as:

	What does "http://example.com:80/..." mean ?
	What does "http://example.com:100/..." mean ?
	And does that depend on you receiving that via HTTP/1 or /2 ?

But my real preference and proposal, is still that we ditch SPDY,
and attack the problem from scratch, somewhat along the what I
started to outline here: http://phk.freebsd.dk/words/httpbis.html

(That was written before I realized that the purpose of this WG was
to gold-plate SPDY and before the "Global War on Privacy" was
demasked, it would need a few tweaks to reflect my current thinking.)

Therefore I'm happy to see that other people have started pushing
for a more envelope/content based scheme which would allow fast
routing and per object cryptographic protection rather than per
session protection.

In addition to the performance benefits, I think that could make
HTTP/2 a much more politically acceptable protocol.

But I find it somewhat futile to move forward at the technical
level, if we can't even agree if the US government banning HTTP/2
should count as success or failure for the WG ?

Maybe we need revisit the "big lines" and agree, or at least
decide, what we're trying to do ?

But as Charles Schultz would have said it:

	  "It's your WG Mark Nottingham."

:-)

Poul-Henning

---

From: Robert Collins <[email-masked]>
Date: Mon, 18 Nov 2013 21:59:11 +1300

> should count as success or failure for the WG ?

You had me right up to here. Has the US government banned SSH ?

-Rob

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Mon, 18 Nov 2013 10:19:06 +0100

Le Lun 18 novembre 2013 04:12, Mark Nottingham a écrit :

> * We can compromise and agree upon when and where HTTP/2 can be used for
> http:// URLs (e.g., for .local and RFC1918 addresses, and/or when
> alternate mechanisms for important aspects of security are layered in,
> whether that's opportunistic encryption or something else). This is where
> I think more discussion will help.

I'm not sure one can identify "internal" addresses technically. "Internal"
corporate wans can be quite large and span multiple continents and address
classes

Regards,

-- 
Nicolas Mailhot

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Nov 2013 20:21:44 +1100

Hi Nicolas, 

> corporate wans can be quite large and span multiple continents and address

This sketch of a proposal wasn’t meant to address that case; it’s more for local / home printers, IoT, etc.

There’s a parallel discussion of “explicit proxies” that is more aimed at the enterprise case, as I understand it. That has very different properties that we need to figure out, of course. 

Cheers,

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 18 Nov 2013 09:31:14 +0000

In message <[email-masked]>
>You had me right up to here. Has the US government banned SSH ?

99.99%+ of the people on the net does not use SSH.

If HTTP/2.0 came out and denied NSA 99% of their take, you can bet
that something political would happen.

Most likely in the form of big vendors being leaned on.

(Why, for instance, do you think VIA could add AES to their CPU
instruction sets, when Intel and AMD could not ?  It's not like
it isn't a very obvious idea, is it ?)

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Nov 2013 20:38:39 +1100

For someone who wanted to keep the discussion technical, PHK, you’re pretty consistent about veering into the political.

The bigger policy decisions are going to happen at the IETF-wide level, so — again — the IETF main list is more appropriate for this discussion.

Please keep it on-topic. 

I’m asking nicely.

Thanks,

---

From: Yoav Nir <[email-masked]>
Date: Mon, 18 Nov 2013 13:18:32 +0200

> If anyone can suggest another realistic approach, we're listening.
I think HTTP is used for so many things in so many scenarios, that 
trying to give general guidance in the base spec is asking for trouble 
(example: when checking certificate revocation, you use HTTP to download 
either a CRL or an OCSP response. You can't use authenticated TLS there).

So I see one additional path forward:

* Say nothing in the base spec, but create an additional document 
targeted for Informational, and called "Recommendations for using HTTP/2 
on the web". Even if that document becomes a tar-pit of political 
discussion, it will allow the base spec to go forward on time.

If, however, we really want to standardize a new port for HTTP/2 in the 
clear (or with opportunistic encryption), that can and should go in the 
base spec, I think.

Yoav

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 18 Nov 2013 11:23:16 +0000

+1

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Nov 2013 22:44:39 +1100

On 18 Nov 2013, at 10:18 pm, Yoav Nir <[email-masked]> wrote:

> I think HTTP is used for so many things in so many scenarios, that trying to give general guidance in the base spec is asking for trouble (example: when checking certificate revocation, you use HTTP to download either a CRL or an OCSP response. You can't use authenticated TLS there).

Again, we’re taking about the case of a browser on the “open” Web — the many special cases don’t apply here.

> * Say nothing in the base spec, but create an additional document targeted for Informational, and called "Recommendations for using HTTP/2 on the web". Even if that document becomes a tar-pit of political discussion, it will allow the base spec to go forward on time.

I had been assuming we’d talk about how to package it down the road, and a “HTTP/2.0 for Browsers” document would be one option. If it makes this discussion easier, assume that we’ll have a separate doc.

Cheers,

---

From: Yoav Nir <[email-masked]>
Date: Mon, 18 Nov 2013 14:19:21 +0200

> Again, we’re taking about the case of a browser on the “open” Web — the many special cases don’t apply here.
I don't think we'll reach consensus on what is appropriate for the open 
web. But I think de-coupling that discussion from the base document is a 
win. I personally don't think that denying the benefits of HTTP/2 to 
websites that choose not to use encryption is justified. But browser 
support will be determined by market forces, unless the browser vendors 
would like to form a benevolent cartel forcing the correct policy on all 
the web.

BTW: Downloading CRLs or OCSP responses to verify certificates used in 
HTTPS is very much part of the open web.

Yoav

---

From: Roberto Peon <[email-masked]>
Date: Mon, 18 Nov 2013 08:41:22 -0800

I suspect when we say "open" internet, we're talking about the "public"
internet, btw.
>From a purely engineering standpoint, we need only to ensure that the
ability to do the "right thing" exists in the protocol by providing for
adequate opt-out or opt-in semantics.
Putting this another way:
The definition of "right thing" varies.
An adequately specified opt-in or opt-out mechanism for encryption allows
for this varied definition.
-=R

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 18 Nov 2013 15:39:49 -0800

On Nov 17, 2013, at 3:40 PM, Mike Belshe wrote:
> So your official statement is that TLS does not improve the security or privacy of HTTP?

I don't make official statements.

rot13 improves privacy, if what you mean by "improve" is that there
exist some tools that do not currently read rotated clear text.
I don't think "improves privacy" is a useful description.
You either have privacy or you don't.

TLS provides security to the extent that it enables systems to be
constructed in a secure manner.  If we follow all of the best
practice, we can deploy a TLS exchange with the same level of
security as using a credit card in a branded establishment that
claims to obey PCI.  That's good enough *when* the user agent
is able to know the end-point of communication to which it wishes
to communicate securely.

TLS alone does not secure https interactions. TLS defines a protocol
for obtaining an authenticated certificate that can be verified to
match a given set of domains.  To the extent that such verification
can be trusted and the domain retains control over its private key,
the connection can be encrypted such that the bytes on the wire
after the key exchange are only visible to the user agent, the
server that decrypts that connection, any observer on either side
of that connection that can see the plain text before encryption
or after decryption, and anyone else with the server's key.

This does not secure the DNS requests that led to obtaining an IP
address, any potentially associated key verification requests, the
destination IP address, and the pattern of subrequests that immediately
follows as a result of the https request.  Each of these is sufficient
to identify what site is being accessed by the user, with the latter
usually being sufficient to identify which common resource is accessed.
They can be seen using the same protocol analyzers that one can see
plain text HTTP/1.1.

Hence, TLS does not provide privacy.  What can be done to provide a
degree of privacy is to route all requests through an encrypted
channel to a trusted intermediary that is shared by enough people
such that it masks *where* the requests are being directed.
That is providing privacy.

Almost all Web sites that use TLS today do so to encrypt the
exchange of user authentication.  User authentication is the
opposite of providing privacy.

In Vancouver, there was a discussion of opportunistic encryption
without server authentication, described as a means of "improving
privacy".  The only way that I can interpret that claim is that
folks don't understand privacy.  If we pretend for a minute that
they aren't just rabble-rousing and actually mean protecting the
confidentiality of user authentication tokens, then using
unauthenticated server certificates is the wrong approach.

This is not an argument against securing Web traffic for the
sake of privacy. It is an argument against window-washing the
subject by applying the wrong tools to the wrong problems.
Go ahead and encourage websites that have user accounts to make
use of https URIs and stay within an encrypted and multiplexed
session, but don't call that privacy.  It is the authenticated
server certificate that provides security of credentials and
the sent message data, which is worthwhile in itself without
mislabeling it as privacy.

If you want privacy against widespread surveillance, then you
need to approach that separately, as a systemic issue involving
all of the network requests and how they are routed, or as a
policy issue that is outside the IETF's scope.

....Roy

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Nov 2013 00:15:02 +0000

Roy,

One request for clarification below:

> You either have privacy or you don't.

Security is less complicated than privacy and is definitely
not a binary property. Privacy is at this point far less
well defined, so I find the last statement above quite hard
to accept. (In fact, I find it unbelievable.) However, privacy
is so ill-defined that its possible you're using some
definition that does support such a binary distinction. FWIW,
I'd be hugely surprised if there were a useful definition in
which privacy was a binary property of systems.

I suspect there's not much point in a blow by blow response
if it turns out our terminology is miles apart in that
respect, so can you provide or point at your definition of
privacy such that its a binary property of systems?

Thanks,
S.

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 19 Nov 2013 14:54:28 +1300

On 2013-11-19 13:15, Stephen Farrell wrote:
>>> On Sun, Nov 17, 2013 at 3:27 PM, Roy T. Fielding wrote:

It assumes privacy is roughly equated with anonymity. Which is what the 
general user population most vocal about either privacy and anonymity 
are also equating. Requesting "cant spy on me" as opposed to accuracy of 
definition for privacy.

> privacy such that its a binary property of systems?

I make the same point when debating anonymous proxy features with users.

They have a binary choice:
0) remove datum X which is used for tracking
1) obscure/replace datum X with Y

NP: What at first thought appears to be a third option "leave datum X 
alone" is actually the case of (1) when X==Y.

So for every action taken on a single users information is exposing at 
minimum 1 bit of information about that user. The level of anonymity is 
part of their uniqueness. Doing (2) only has benefit if Y is more common 
than X. Thus the special case of X==Y (status quo) is the common case of 
most benefit.

Tradoff is privacy vs security. It is exceedingly difficult to have both 
simultaneously. Perfect for both means being cut off from the 
communication channel entirely. Up to that point there is a weakest-link 
situation where the stronger either becomes the more vulnerable it is to 
holes in the other.

Privacy requires that no one user can be separated from the crowd. The 
safest action is to take N users data and jumble it all up - 
invisibility/anonymity/privacy by obscurity. Encryption / signing 
prohibits these protection actions.

TLS and similar end-to-end channels offer clear end-to-end separation of 
each individual clients data (albeit encrypted). Such that individual 
user tracking improves to near 100% capability for any Big Brother 
entity. Each endpoint has full tracking ability for the connection, and 
big brother in the middle is provided with the guarantee that all bits 
of the stream are present and in the sequence visible to it.

Traffic which is allowed to be multiplexed by middleware becomes a far 
more jumbled "mess" of packets/frames across the network. The endpoints 
have no change to their abilities, but Big Brother in the middle has 
lost the guarantee of seeing everything at a single choke point, or 
getting it in the right order to identify an individual. It can still do 
that, but must cast a far wider net for less gain.

High quality protection ("security", "privacy", whatever you want to 
call it) is best when it involves a mixture of the two approaches. 
Encrypting what needs to be hidden while simultaneously jumbling the 
critical bits amidst similar chaff from numerous other sources (on the 
server end) or destinations (on the client end). This is one key 
security property a middleware topology (dare I call it "cloud"?) 
offers.

Amos

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 19 Nov 2013 14:26:27 +1100

On 18/11/2013, at 11:19 PM, Yoav Nir <[email-masked]> wrote:

> I don't think we'll reach consensus on what is appropriate for the open web. But I think de-coupling that discussion from the base document is a win. I personally don't think that denying the benefits of HTTP/2 to websites that choose not to use encryption is justified. But browser support will be determined by market forces, unless the browser vendors would like to form a benevolent cartel forcing the correct policy on all the web.

Right. This is where we started in Berlin -- that market forces could take care of this, based upon the stated preferences of peers and a good negotiation mechanism. We went back and forth on the negotiation mechanism and got to a place where the simplest  -- using https:// + ALPN -- was most attractive to the browser implementers that care about this issue -- at least for now.

We absolutely can leave this up to the market by not saying anything in our document; I said as much last week:

> This can be effected without any changes to our current document; browser vendors are not required to implement HTTP/2.0 for http:// URIs today.

My concern is that this path of least resistance will be poor for interop. *If* it really is as simple as "we only do this over https://" that concern may fade, but more nuance can bring deployment problems. 

For example, if browsers start trying to address the "local printers/IoT" problem by selectively dropping the requirement for https:// URIs, there's a very real chance that they'll do so in slightly different ways.

Some are also concerned that this looks too much like the "do nothing" option; personally I'm not as worried about that, because at least a large portion of the browsers (by all indications so far) *are* going to do something.

So, we could go ahead and specify:
  a) how to use HTTP/2 for http:// URIs (without TLS)
  b) how to use HTTP/2 with https:// URLs (with TLS)
  c) how to opportunistically encrypt HTTP -- both 1 and 2 -- for http:// URLs
... and let the market choose what it wants to implement.

We're already working on (a), (b) is pretty much baked, and we have made a fair amount of progress on staking out (c). 

It may be that browsers start by implementing (b), after evaluating the market (and adoption rates of the current plan), decide to implement (c). Or not. If they implement (a), we'd need to stay on top of the potential interop problems (such as that described above). In the end, they might decide that doing that is too much trouble, and leave http:// URIs on HTTP/1.1. That doesn't remove all the value from (a); it just means that it'll be relegated to non-browser uses of HTTP.

There could even be a (d), if the TLS-inside-of-HTTP2 discussion gets some running code behind it.

There's also a fair amount of follow-on work that we need to consider in any case; e.g., explicit proxies, TLS profiling / requirements, and liaison for things like security UX and TLS MITM.

> BTW: Downloading CRLs or OCSP responses to verify certificates used in HTTPS is very much part of the open web.

Depending on how you define "open web" for this discussion, yes or no; we haven't gone there yet.

Cheers,

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 19 Nov 2013 00:43:44 -0800

> which privacy was a binary property of systems.

I think you misunderstood what I said.  It isn't the system
that has privacy (or not) -- it is the user of the system.

If you want a deeper survey of privacy, look at

  http://tools.ietf.org/html/rfc6973

and its references.  Or spend two years arguing about what DNT: 1
is supposed to do.

I don't think security is less complicated than privacy.  It is just
a little easier to talk about because security folks generally refer
to something specific being secured.  As in, the dead-bolt secures
the door.  We don't say the dead-bolt secures the house, since there
are probably many other entrances to the houses, nor do we make
judgement calls on whether being inside the house is secure
(e.g., it's not when the house is on fire).  Privacy literature
often does both.

When people talk about "levels of security" they are generally
referring to strength (resistance to brute force attacks) or
comprehensiveness (does it cover everything you want secured).
But when the thing being secured is information, the result is
mostly binary for the user: either the information is secure
or somebody can see something that they shouldn't be able to see.
Actually, I guess we could say that revealing only metadata about
secured data is a sort of middle ground, but I digress ...

People here talk about securing http because they assume that
hiding the information exchanged is a useful act.  There are
certainly cases where that is true, and for which we should
recommend, or even insist on, the use of https (or some other
secure transport).  For all of those cases, a user agent needs
to verify that only the intended recipient can read the information,
before the information is sent, which is why we have the https scheme.

However, there are far more cases where encapsulating the entire
message exchange in encryption will do nothing of value.  The
only "private" information being exposed in HTTP is the same
information that is exposed by requesting DNS, making the connection,
and reacting to the results.  Opportunistic encryption in those
cases is both unwanted by the server and useless for the user.

Furthermore, I have a hard time believing the privacy propaganda
being spread by the browser makers.  If they want to improve
privacy, all they have to do is remove the crappy features
that cause their HTTP use to be insecure.  Stop blaming the
protocols for exposing information that shouldn't be sent in
the first place.

Don't allow cookies from a secure site to be sent to a non-secured site.
Double-key cookies so that they don't share information across multiple
referring sites. Implement an obvious logout in the UI chrome.
Don't send cached credentials if the referring document isn't trusted
or same-origin.  Don't allow BASIC over an unsecured connection.
Implement authentication schemes that don't expose the user's secret.
Prevent extensions and scripts from mimicking authentication forms.

Those are just the easy fixes. Sure, some of those changes
will fail to interop with some sites. Deal with it. That is a
tiny price to pay when compared to insisting that all http
traffic be encrypted.

....Roy

---

From: Mike Belshe <[email-masked]>
Date: Tue, 19 Nov 2013 01:45:14 -0800

On Mon, Nov 18, 2013 at 3:39 PM, Roy T. Fielding <[email-masked]> wrote:

> On Sun, Nov 17, 2013 at 3:27 PM, Roy T. Fielding <[email-masked]>wrote:
>

Alright, well thats all fine, but I really don't know why you're going off
on this rant.    Can you cite for me the specific quote from anyone on this
list who declared or implied that TLS was a comprehensive solution for
'security' or 'privacy'?  I don't think anyone did, so this rant is really
unnecessary.

The reason we're talking about TLS is because this is the HTTP team,
responsible for how the bits fly over the transport.  We can't control what
happens before or after that.  So the question that is before us is:  can
we make our piece more secure?  more protected against privacy leaks?  I
believe the answer is yes.

We know that cleartext is readable by all, so even rot-13, as you so
sarcastically put forth, would be an improvement.  But we can do a lot
better than rot-13 as well, with TLS.  TLS simultaneously addresses two key
points:  verification of identity of the server and establishing an
encrypted session.  We know that there are individuals siphoning off
packets from the routing infrastructure today.   It's just silly to argue
that TLS isn't substantially better than cleartext in this case.  Am I
saying it is impermeable?  No.  But a way more private and secure way to
transmit your bits.

Mike

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 19 Nov 2013 10:04:12 +0000

In message <[email-masked]>, "Roy T. Fielding" w
rites:

>privacy".

I hate to go into lecture mode, but there are clearly people in
this discussion who are not aligned on their use of the word
"privacy".

"Privacy" comes in two major categories:

"Second person privacy" is what your communication leaks to the
intentional partner in the communication, and it is very much
related to the concept of anonymity, but not identical with it.

Second person privacy comes in active and passive forms.

Passive form is what information the second part receives
without doing anything extra:  Your IP number, Your User-Agent
string, Referrer, GPS coordinates or whatever your browser blabbers.

Active form is what they can glean by trying:  Cookies, nefarious
use of If-* conditionals, query-strings, cross site "like this"
buttons and so on.

Second person privacy takes a lot of effort.

Ultimately TOR-like NSAP obfuscation is a necessary but not sufficient
requirement, but the browser-vendors could certainly do more than
they do today, but that would seem to hurt business models they
care about.

"Third person privacy" is about what information a non-party to a
communication can glean from watching the traffic.

This is your mail-man reading your X-mas postcards, this is your
telco trying to sell your demographics and this is the secret service
wanting to know if you plan "terror".

Opportunistic encryption or in fact *any* encryption, even rot13,
improves your third party privacy.

Rot13 is a quite good defense against simplictic keyword scanning,
but for more determined 3rd parties, you obviously want better
encryption and to be sure that only you and the other intended
party of the communication knows the encryption key.

Please notice that authentication is 100% orthogonal to privacy:

I dont care who the stranger I ask for directions is, but I certainly
do not want him to know who asked for directions to Alcoholics
Anonymous.

Please everybody:  Qualify the word "privacy", so we know what
you're actually talking about.

Thanks,

Poul-Henning

---

From: Mike Belshe <[email-masked]>
Date: Tue, 19 Nov 2013 02:28:41 -0800

> (e.g., it's not when the house is on fire).  Privacy literature

Nobody here said that TLS was the one-true  deadbolt.

> secured data is a sort of middle ground, but I digress ...

Again, nobody claimed that TLS would solve all levels of security that
anyone on this list can dream up.

The leap you're making is your conclusion that TLS is not useful as a
default option because it doesn't solve every level of security.

> cases is both unwanted by the server and useless for the user.

Nonono - this is definitely not true.  Cookies contain orders of magnitude
more personal information than a DNS request generally does.

I'm not saying that DNS exposure isn't an issue, but just because we don't
solve it with TLS doesn't mean that TLS is bad.

> protocols for exposing information that shouldn't be sent in

Patches are always welcome.  Sounds like you've got it all figured out.

> Prevent extensions and scripts from mimicking authentication forms.

Well, cookies are part of HTTP, so....  But seriously, just encrypt the
session, and your cookies get a lot more manageable.  Nothing new needs to
be invented - we have this technology right now.

You're focusing on one level, and ignoring the very real, and now
documented threat of widespread and massive data theft at the internet
routing points.

> tiny price to pay when compared to insisting that all http

Despite the grandstanding on here, we all know that TLS is relatively cheap
already and getting cheaper every day.  If we standardize around it, and
work on tools a little, it'll get even cheaper.  But I don't expect to get
agreement on this point.

One last thing I want to mention is that the downsides of using TLS are a
lot less than the downsides of not using TLS.

As we're all aware, there are about 200 countries on this planet.  Many of
the governments of these countries are using packet siphoning as a key
information gathering technique.  It's easy today.  They do this for many
protocols beyond just HTTP.  But what do they do with this information?  We
know the answer to this too - they are out to kill their dissidents.

So when we don't protect everything from generic siphoning, we are
facilitating murders and genocides.  Is this dramatic?  Yeah its dramatic.
 But is it untrue?  No.  I know the counter argument already!  You'll say
"but we already MITM!", and pretend that MITM is just as easy as siphoning
cleartext when we know that its not even close to the same thing. TLS does
make raw siphoning of packets orders of magnitude more expensive and
difficult to do.  Or you'll say "but DNS is exposed!", as though DNS were
on the same level as words and phrases that you communicate with other
people.  Or you'll say, "but SMTP is cleartext", as though we have to
secure every last possible door if we secure any of them... Sigh.

I am not sure what the next 10 years will bring.  But I am certain it will
bring many incidents where we'll be able to look back and say, "hmmm... if
we had put TLS in HTTP by default, that might not have happened."

People don't die because we did put in TLS.  They only die if we don't.

Dramatically yours,
Mike

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Nov 2013 11:29:46 +0000

Hiya,

A bit of disagreement and agreement...

> cases is both unwanted by the server and useless for the user.

So I disagree there. Encrypting more or all HTTP traffic would
add value IMO. Given that only 30% of sites appear to have
server-certs that chain up to a browser-trusted root, there is
a lot of plaintext being sent that contains sensitive information.
For example, I'd bet that the pattern of cleartext http:// URI
accesses for images or whatever that an https:// page load
causes would I'm sure be nicely identifying of a user or of
transaction details in many cases and if so, that's a pure
HTTP protocol effect that no DNS changes could fix.

And site-authors are not perfect, so if we can do better by
sending more HTTP via TLS, then there are real benefits right
now, in that sensitive data that should have used https://
URIs but doesn't will get some better protection.

Saying that's useless for the user is just overstatement.
Yes, there's a cost for the server, but that cost is today
far far more tractable than it was 20 years ago. That does
require the wg to figure out how exactly to do more TLS, and
there are some tricky bits to that, as the recent torrent
of mail shows, but I'm still very hopeful that the wg will
figure it out.

And yes, there are other things like DNS to consider (and some
people are looking at the DNS confidentiality issue [1]) but
that doesn't mean that one shouldn't also look at how to
encrypt more HTTP traffic.

   [1] http://www.ietf.org/mail-archive/web/perpass/current/msg00378.html

> protocols for exposing information that shouldn't be sent in

I'm somewhat in agreement with you there. I think it'd be
better if the browser folks talked about adding encryption
or confidentiality and didn't talk about that as being the
same as privacy since it is not. Actually, I think they
have gotten better in that respect, at least in the IETF
context. And I'm sure there's an awful lot more that could
be done both by browsers and web sites to be more privacy
friendly.

But overall, getting more confidentiality is a pre-requisite
for eventually getting more privacy, but confidentiality
(whether via authenticated keying or not) is definitely
not sufficient to make a claim that the web will overall be
much more privacy friendly. If the web is being used to
collect every possible morsel of data about users then it is
not at all privacy friendly, and that is the status quo as
far as I can see. But even so, adding more confidentiality
is a necessary step in the right direction for those who
would like to eventually get to a more privacy friendly web.
And that necessary step also has real security benefits now,
aside from enabling a possible future that is more privacy
friendly.

Cheers,
S.

---

From: Albert Lunde <[email-masked]>
Date: Tue, 19 Nov 2013 08:33:14 -0600

I'm not sure how "opportunistic encryption" of traffic without 
validation of server certificates would be defended against active 
man-in-middle attacks. (Not unlike the attack on Tor, or less elaborate 
sorts of DNS spoofing.)

https://www.schneier.com/blog/archives/2013/10/how_the_nsa_att.html

It's outside the HTTP protocol as such, but without additional security 
measures, such as have already been mentioned, using TLS without server 
validation seems fundamentally unreliable.

With so much of JavaScript and Flash security based on "trusted" 
origins, the browser environment seems at risk from server spoofing or 
session hijacking by various bad actors.  The "mixed content" risks come 
from a more complicated mix of threats than passive eavesdropping alone.

This may be mostly the outside this working group's activity but it at 
least bears on security considerations.

Plaintext HTTP still seems like it might be useful, but the contexts 
where that is true are getting more specialized. At the same time, TLS 
is not a cure-all.

---

From: Michael Sweet <[email-masked]>
Date: Tue, 19 Nov 2013 09:38:44 -0500

Mike,

On Nov 19, 2013, at 5:28 AM, Mike Belshe <[email-masked]> wrote:
> ...
> I am not sure what the next 10 years will bring.  But I am certain it will bring many incidents where we'll be able to look back and say, "hmmm... if we had put TLS in HTTP by default, that might not have happened."
>  

I know you are trying to be dramatic here, but I don't think "think of the children" arguments have any place here.

We can say we have an ethical obligation to support greater confidentiality/third-party privacy in HTTP (whatever version is used).  We can even say that TLS is one tool for the job that can make it harder for third parties to casually collect information about a person that is accessing a particular web site, and increased usage of https:// for web sites that store and/or provide Personally Identifying Information (PII) and/or other sensitive information is both recommended and useful.

But to dramatically state that adding TLS will prevent deaths is both technically inaccurate (TLS is only one piece of a much bigger set of changes that are needed, and technology is only one tool used by oppressive regimes) and does not convince me in the least - in fact, if I was a paranoid person it would have the opposite effect - why are you so focused on TLS, what have you to gain, etc.

I think it is important to recognize that we *cannot* secure the Internet, we can only make it harder for "the bad guys" to figure out what "the good guys" are doing.  But in doing so we also need to balance security against what "the good guys" need to know to protect other "good guys" from "the bad guys" (malware filtering, etc.)

Finally, I think it is a mistake to tie improved security/confidentiality/privacy to HTTP/2. It will take a while for ISPs, web sites, browsers, and proxy vendors to properly support HTTP/2, and everything we have talked about WRT TLS and HTTP/2 (minus maybe TLS-encrypted message bodies) applies equally to HTTP/1.x.  Clearly there are recommendations that we can make today (best practices, deployment strategies, etc.) to provide a "safer" web browsing experience.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Nov 2013 15:10:23 +0000

On 11/19/2013 02:33 PM, Albert Lunde wrote:
> man-in-middle attacks.

Opportunistic encryption that is vulnerable to mitm attacks
can still be valuable.

It turns what can otherwise be a passive attack into a
requirement to mount an active attack.

Active attacks are more expensive to mount, and much more
expensive to do at v. large scale, and perhaps more importantly
can be detected in some cases, e.g. via later comparisons
of session keys used. If pervasive active attacks were to be
attempted, then those could probably be detected via some
kind of observatory. Passively tapping a fibre and snarfing
plaintext is essentially not detectable and apparently is
not too expensive for some. And is liable to get cheaper
and become more common for more attackers now that the
world knows all about it.

Having said that, for the web, server-authenticated TLS
is better if it we can get it closer to ubiquitous, which
is the current plan.

But one could make a reasonable argument though that
there is a smaller barrier facing the introduction of
non-server-auth or opportunistic TLS, due to not having to
deal with CAs.

TLS has also supported anonymous diffie-hellman key
exchange since way back and that is apparently relatively
widely implemented at least in libraries. I'm not sure
about web servers or browsers, nor about how good the
interop situation is though. Those ciphersuites already
provide the kind of opportunistic encryption we're talking
about here, for example TLS_DH_anon_WITH_AES_128_GCM_SHA256,
though again, I don't know if that specific one is readily
available today or not, and that is different from the
draft that Mark wrote about opportunistic encryption for
HTTP before Vancouver.

So if the httpbis wg do want to explore that avenue then
that would be reasonable and has real benefits and there
are sensible ways to go about the work.

S.

---

From: James M Snell <[email-masked]>
Date: Tue, 19 Nov 2013 08:38:00 -0800

On Tue, Nov 19, 2013 at 6:38 AM, Michael Sweet <[email-masked]> wrote:
[snip]
> children" arguments have any place here.

+1 ... honestly, this whole conversation seems to be getting lost in
the weeds, really. Personally, I don't really care whose definition of
"privacy" is more accurate. It would be fantastic if we could get back
to discussing actual technical details. TLS gives us reasonably good
confidentiality of the data in motion over a TCP/IP connection. No, it
doesn't provide privacy, but it addresses at least part of the overall
problem and it's quite useful to adopt as the default option in
probably 95% of our primary use cases. So Mark's proposal suggesting
that we limit plaintext http/2 on port 80 to .local and rfc1918
addresses appears completely reasonable so long as we take the
additional step of defining a new default port for plaintext http/2
everywhere else. If we can get agreement on that one technical point
(as opposed to endless debating about what "privacy" really means)
then we've made progress and can move on to the other important
questions.

- James

---

From: Mike Belshe <[email-masked]>
Date: Tue, 19 Nov 2013 09:00:22 -0800

On Tue, Nov 19, 2013 at 6:38 AM, Michael Sweet <[email-masked]> wrote:

> We can say we have an ethical obligation to support greater
> confidentiality/third-party privacy in HTTP (whatever version is used).  We
> can even say that TLS is one tool for the job that can make it harder for
> third parties to casually collect information about a person that is
> accessing a particular web site, and increased usage of https:// for web
> sites that store and/or provide Personally Identifying Information (PII)
> and/or other sensitive information is both recommended and useful.
>
> But to dramatically state that adding TLS will prevent deaths is both
> technically inaccurate (TLS is only one piece of a much bigger set of
> changes that are needed, and technology is only one tool used by oppressive
> regimes)
>

You mention the answer to this question later - that we just keep raising
the bar on security, not solving it.  And TLS would be a key step in
raising the bar.  It also happens to be the only one this group controls -
we don't have scope over dns, email, and other areas that would need work
too.  Does that mean we have to do nothing?

People do die because of unencrypted HTTP.  I'm not sure how many
governments have to get caught before you'll agree with this fact.  From
from Iran to China to the US, this is widespread.

> and does not convince me in the least - in fact, if I was a paranoid
> person it would have the opposite effect - why are you so focused on TLS,
> what have you to gain, etc.
>

You're welcome to investigate me, I have nothing to gain.  I'm not a proxy
writer like most of the anti-TLS people, and have zero investments or ties
or obligations to TLS vendors.

>
> I think it is important to recognize that we *cannot* secure the Internet,
> we can only make it harder for "the bad guys" to figure out what "the good
> guys" are doing.  But in doing so we also need to balance security against
> what "the good guys" need to know to protect other "good guys" from "the
> bad guys" (malware filtering, etc.)
>

You're alluding to something here; but I'm not sure what it is.  TLS does
not prevent the good guys from doing anything.  Maybe you think the NSA is
the good guys?  :-)

>
> Finally, I think it is a mistake to tie improved
> security/confidentiality/privacy to HTTP/2. It will take a while for ISPs,
> web sites, browsers, and proxy vendors to properly support HTTP/2, and
> everything we have talked about WRT TLS and HTTP/2 (minus maybe
> TLS-encrypted message bodies) applies equally to HTTP/1.x.  Clearly there
> are recommendations that we can make today (best practices, deployment
> strategies, etc.) to provide a "safer" web browsing experience.
>
>
Well, it took 15 years to change HTTP/1.1.  It'll likely be 15 years before
we change HTTP/2.  So if you say "not now", then the question becomes when?
 Because the next likely opportunity is 2025-2030.  Recommendations are
weak; and having an unsecured mode leads to broken security UIs for which
we've all seen the research that shows it doesn't work.  When do we want to
get serious about fixing this?

We can design for the past - where it was harder to get TLS going and where
middleware proxies served a small role.  Or we can design for the future,
where it will continue to get easier and easier to rollout TLS.  And with a
little prodding from this group, we can take the tooling to a new level.
 And we can fix the biggest issues in  TLS!  But the first step is for us
to want it now.

I'm designing for the future. Its not a comprehensive plan, its just the
first small step.

Mike

---

From: Michael Sweet <[email-masked]>
Date: Tue, 19 Nov 2013 12:12:11 -0500

James,

Mark’s proposal is the first one that could actually be expressed as a conformance requirement, but I’d also like to give the delayed plaintext HTTP/2.0 upgrade approach a try - to reiterate, don’t allow the client to perform an upgrade until it sees an Upgrade: HTTP/2.0 header from a server response.

My hope is that while some HTTP proxies are broken WRT the headers that are sent up from the client to the server, they may be more careful about the headers from the server that they return to the client.  And in many cases the proxy is generating its own response headers to provide cached content.

This would also provide a way to support HTTP/2.0 (plaintext) proxies in the future.

(it *would* be nice to know which HTTP proxies have problems with the current HTTP/2.0 upgrade approach so I/we can test the delayed upgrade approach…)

> then we've made progress and can move on to the other important

_______________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Tue, 19 Nov 2013 20:00:17 +0100

> Prevent extensions and scripts from mimicking authentication forms.

Stop sending referers…

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Tue, 19 Nov 2013 20:07:15 +0100

> 'security' or 'privacy'?  I don't think anyone did, so this rant is really

That's playing with words, Chrome and Mozilla representatives have been
quite clear they wanted to force a TLS-only web for 'security' and
'privacy'. Even though there is a ton of things those browsers could do
*now* to improve privacy without fostering pki on everyone else.

Really, it's getting quite annoying to see all this forceful selling of
TLS in the name of privacy and security while systematically stonewalling
any attempt to consider the parts of the protocol that are used to data
mine users now (let's use the business term not emotional appeals).

-- 
Nicolas Mailhot

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 19 Nov 2013 19:50:42 +0000

Hey Mike

if you stop for a minute and think about it.  Why do you think it's the 
proxy/intermediate authors that have the problem with mandatory TLS?

Adrien

------ Original Message ------
From: "Mike Belshe" <[email-masked]>
To: "httpbis mailing list" <[email-masked]>
Sent: 20/11/2013 6:00:22 a.m.
Subject: Fwd: A proposal
>>>I am not sure what the next 10 years will bring.  But I am certain it 
>>>will bring many incidents where we'll be able to look back and say, 
>>>"hmmm... if we had put TLS in HTTP by default, that might not have 
>>>happened."
>>>
>>I know you are trying to be dramatic here, but I don't think "think of 
>>the children" arguments have any place here.
>>
>>confidentiality/third-party privacy in HTTP (whatever version is 
>>used).  We can even say that TLS is one tool for the job that can make 
>>it harder for third parties to casually collect information about a 
>>person that is accessing a particular web site, and increased usage of 
>>https:// for web sites that store and/or provide Personally 
>>Identifying Information (PII) and/or other sensitive information is 
>>both recommended and useful.
>>
>>changes that are needed, and technology is only one tool used by 
>>oppressive regimes)
>
>You mention the answer to this question later - that we just keep 
>raising the bar on security, not solving it.  And TLS would be a key 
>step in raising the bar.  It also happens to be the only one this group 
>controls - we don't have scope over dns, email, and other areas that 
>would need work too.  Does that mean we have to do nothing?
>
>governments have to get caught before you'll agree with this fact.  
>From from Iran to China to the US, this is widespread.
>
>
>>person it would have the opposite effect - why are you so focused on 
>>TLS, what have you to gain, etc.
>
>You're welcome to investigate me, I have nothing to gain.  I'm not a 
>proxy writer like most of the anti-TLS people, and have zero 
>investments or ties or obligations to TLS vendors.
>
>>
>>I think it is important to recognize that we *cannot* secure the 
>>Internet, we can only make it harder for "the bad guys" to figure out 
>>what "the good guys" are doing.  But in doing so we also need to 
>>balance security against what "the good guys" need to know to protect 
>>other "good guys" from "the bad guys" (malware filtering, etc.)
>
>You're alluding to something here; but I'm not sure what it is.  TLS 
>does not prevent the good guys from doing anything.  Maybe you think 
>the NSA is the good guys?  :-)
>
>
>>
>>security/confidentiality/privacy to HTTP/2. It will take a while for 
>>ISPs, web sites, browsers, and proxy vendors to properly support 
>>HTTP/2, and everything we have talked about WRT TLS and HTTP/2 (minus 
>>maybe TLS-encrypted message bodies) applies equally to HTTP/1.x.  
>>Clearly there are recommendations that we can make today (best 
>>practices, deployment strategies, etc.) to provide a "safer" web 
>>browsing experience.
>>
>
>Well, it took 15 years to change HTTP/1.1.  It'll likely be 15 years 
>before we change HTTP/2.  So if you say "not now", then the question 
>becomes when?  Because the next likely opportunity is 2025-2030.  
>Recommendations are weak; and having an unsecured mode leads to broken 
>security UIs for which we've all seen the research that shows it 
>doesn't work.  When do we want to get serious about fixing this?
>
>We can design for the past - where it was harder to get TLS going and 
>where middleware proxies served a small role.  Or we can design for the 
>future, where it will continue to get easier and easier to rollout TLS. 
>  And with a little prodding from this group, we can take the tooling to 
>a new level.  And we can fix the biggest issues in  TLS!  But the first 
>step is for us to want it now.
>
>I'm designing for the future. Its not a comprehensive plan, its just 
>the first small step.
>
>Mike
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Nov 2013 21:52:08 +0000

Hiya,

On 11/19/2013 07:07 PM, Nicolas Mailhot wrote:
> 'privacy'. 

To be fair, I don't think its only them.

> Even though there is a ton of things those browsers could do

And in fact progress on the TLS front can be made without needing
to hook every site into the WebPKI, but that depends on the
approach that the WG take.

So "fostering PKI" isn't right (and maybe you meant foisting
PKI), but as has been said before there is clear value in doing
more HTTP over TLS even if the wg choose to take the route
where the WebPKI is needed for more TLS.

> mine users now (let's use the business term not emotional appeals).

On that last - I've not seen any drafts or worked out suggestions
for such. I can see that it might be de-motivating to do that
work if you don't think browsers would adopt it, and it might not
be within this wg's current charter, but discussion of such *is* in
scope for the perpass list and, possibly, the websec wg, depending
on where it went. I'd encourage you to write a draft on that topic,
and post there, keeping it separate from TLS related issues, since
it is and should be separate. While data minimisation stuff is
hard, its also something that we need to look at, perhaps longer
term, but we shouldn't forget it.

Cheers,
S.

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 19 Nov 2013 22:04:52 +0000

it is interesting the biggest pushers of mandatory TLS are those who 
stand to suffer the least from it.  Browser makers.

Are any server makers or (reverse-) proxy makers here proponents of 
mandatory TLS?  I can't imagine a server author taking the step of 
requiring all their customers to suddenly buy certs.  At least not be 
the first to do so.  They are the ones who will have to deal with the 
backlash and incredible inertia of getting their customers to change.

Without servers supporting mandatory TLS, it's kinda pointless for 
browser makers to assert they won't implement plaintext http/2.0.  Since 
the cert must be installed on the server (not the client/browser), I 
think it would be better to let the server authors take the lead on this 
surely?

Adrien

------ Original Message ------
From: "Nicolas Mailhot" <[email-masked]>
To: "Mike Belshe" <[email-masked]>
Cc: "Roy T. Fielding" <[email-masked]>; "HTTP Working Group" 
<[email-masked]>
Sent: 20/11/2013 8:07:15 a.m.
Subject: Re: A proposal

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Nov 2013 15:11:50 -0700

On 11/19/13 3:04 PM, Adrien de Croy wrote:

> I can't imagine a server author taking the step of requiring all
> their customers to suddenly buy certs.

Using TLS does not mean one needs to buy a PKIX certificate from a CA.
Some CAs issue free certificates, one can use self-signed
certificates, one can provision keys in DNS (DANE/TLSA), one can use
PGP keys, one can use anonymous DH cipher suites, etc. You might think
some of those options are non-starters, but it's incorrect to say that
mandatory TLS means we're forcing people to buy certificates from CAs.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 19 Nov 2013 22:15:07 +0000

even if a cert is $0 it is not zero cost.

Time and effort are not free.

All these options involve an ongoing management/maintenance cost as well

And are we really proposing the internet should be built on certs from 
free cert providers?  How will they stay in business or the certs remain 
free once the demand for free certs is multiplied by several orders of 
magnitude?

------ Original Message ------
From: "Peter Saint-Andre" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>; "Nicolas Mailhot" 
<[email-masked]>; "Mike Belshe" <[email-masked]>
Cc: "Roy T. Fielding" <[email-masked]>; "HTTP Working Group" 
<[email-masked]>
Sent: 20/11/2013 11:11:50 a.m.
Subject: Re: A proposal
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
>Comment: GPGTools - http://gpgtools.org
>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
>iQIcBAEBAgAGBQJSi+ImAAoJEOoGpJErxa2pD2cQAIOOmeDRRbwi8I0Tf05FUmwi
>RE7Tl0w4L1NtOhU4xCbGkCkWcx6h/i/v2vxSzBo6DCloka4yrr2SC0cvJ7HHQoBK
>ikv8b8n4wHJbZFWS6pBda57kN8yHYpgnX3TKvTSrqU02UC6rFHJKKEmt2RJD6glW
>ijIBhyUt72aXLg9Ujog4+5dbLu/7FNx3CpyAUnNyzRNXVqV6hdekmdZgNU1RFWNc
>agZMDeDGud+9IdE4JKiocCtI85g3j/VMgJI2V6iUCfqMe3jf6IV/NGerKYl8qIG4
>dC1EyOuPB3FPaaRMcK+dAFc/0urfUQ8rVIEQNCodZTLx1KDfyQVj2gL11Lr6lFdy
>XDuZBQr8V+BB2cQj3u5gjCT9qW0L9g4oJwbJWD+vvm4R3/jkCHFKf2wPwmQIJYdi
>402S/X7xK0AjMs2/rI4P8oh2mhzEnx//LvwSb+dosrTi3i28WzHW2NN8NQ++vOxj
>PKjqN7d7eCl74dPL4g8Hfd/SI8XBs8ceoL8F/O6L6FEbtb4t9e4dUemm7/WDhmqe
>KxTORv9zgNS41xx9C7/bxowTJvH2qovvwpxpq967OAvL/jKO0CUlfzqZnOg4fc3N
>MaeyOn7M+cFHPJcakamssCwawIRdvzjIJoxDBl1FNcRmv0Nv2vaLYiuuh5/SheFI
>x6ZkFnhokPzHNSMCru1l
>=s1AS
>-----END PGP SIGNATURE-----

---

From: Roberto Peon <[email-masked]>
Date: Tue, 19 Nov 2013 14:18:18 -0800

I don't want the headaches of attempting to support something non-encrypted
over the public internet and would rather just deal with HTTP/1.1 in the
cases where encryption is disallowed or is not negotiated.
-=R

On Tue, Nov 19, 2013 at 2:04 PM, Adrien de Croy <[email-masked]> wrote:

>
> it is interesting the biggest pushers of mandatory TLS are those who stand
> to suffer the least from it.  Browser makers.
>
> requiring all their customers to suddenly buy certs.  At least not be the
> first to do so.  They are the ones who will have to deal with the backlash
> and incredible inertia of getting their customers to change.
>
> Without servers supporting mandatory TLS, it's kinda pointless for browser
> makers to assert they won't implement plaintext http/2.0.  Since the cert
> must be installed on the server (not the client/browser), I think it would
> be better to let the server authors take the lead on this surely?
>
>
> Adrien
>
>
> Cc: "Roy T. Fielding" <[email-masked]>; "HTTP Working Group" <
> [email-masked]>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Nov 2013 22:20:36 +0000

> All these options involve an ongoing management/maintenance cost as well

Wrong. Anon-DH requires no maintenance at all.

Not just getting at only you, but this discussion would be a
lot easier if it were fact-based.

S.

---

From: Zhong Yu <[email-masked]>
Date: Tue, 19 Nov 2013 16:21:23 -0600

Fortunately, a server with plaintext http/2 can always advise users to
use Internet Explorer for better experience. Thank Microsoft.

Zhong Yu

On Tue, Nov 19, 2013 at 4:04 PM, Adrien de Croy <[email-masked]> wrote:
> mandatory TLS?  I can't imagine a server author taking the step of requiring
> all their customers to suddenly buy certs.  At least not be the first to do
> so.  They are the ones who will have to deal with the backlash and
> incredible inertia of getting their customers to change.
>

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 19 Nov 2013 22:22:14 +0000

I think if the world moved to plaintext http/2.0, you would find that 
would become supported in Chrome.

Because you know what people do when their browser can't view a site.

------ Original Message ------
From: "Roberto Peon" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Nicolas Mailhot" <[email-masked]>; "Mike Belshe" 
<[email-masked]>; "Roy T. Fielding" <[email-masked]>; "HTTP Working 
Group" <[email-masked]>
Sent: 20/11/2013 11:18:18 a.m.
Subject: Re: A proposal
>I don't want the headaches of attempting to support something 
>non-encrypted over the public internet and would rather just deal with 
>HTTP/1.1 in the cases where encryption is disallowed or is not 
>negotiated.
>-=R
>
>
>>browser makers to assert they won't implement plaintext http/2.0.  
>>Since the cert must be installed on the server (not the 
>>client/browser), I think it would be better to let the server authors 
>>take the lead on this surely?
>>
>>
>>Adrien
>>
>>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 19 Nov 2013 22:24:57 +0000

In message <em391973eb-e13a-41d4-b8ed-97b9c30fb142@bodybag>, "Adrien de Croy" w
rites:

>Are any server makers or (reverse-) proxy makers here proponents of=20
>mandatory TLS?

The official position on Varnish is unchanged:

	https://www.varnish-cache.org/docs/trunk/phk/ssl.html

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 19 Nov 2013 22:32:14 +0000

it would be interesting to get (if they have one) an official MS view on 
this.

Given that they also make web servers, it would be even more 
interesting.

It's interesting to play out the scenario from a server vendor 
perspective.

------ Original Message ------
From: "Zhong Yu" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Nicolas Mailhot" <[email-masked]>; "Mike Belshe" 
<[email-masked]>; "Roy T. Fielding" <[email-masked]>; "HTTP Working 
Group" <[email-masked]>
Sent: 20/11/2013 11:21:23 a.m.
Subject: Re: A proposal
>>stand
>>requiring
>>browser
>>>>   Alright, well thats all fine, but I really don't know why you're 
>>>>going
>>>>  off
>>>>   on this rant. Can you cite for me the specific quote from anyone 
>>>>on
>>>>   this

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 19 Nov 2013 23:33:17 +0100

>mandatory TLS means we're forcing people to buy certificates from CAs.

We should assume that none of the options you list are available unless
mandatory TLS means that we're forcing people to implement them. I have
no difficulty imaging a major browser vendor announcing they will, say,
no longer connect to sites with free or self-signed certificates, with
no option for the user to override.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: David Morris <[email-masked]>
Date: Tue, 19 Nov 2013 14:47:05 -0800 (PST)

> Wrong. Anon-DH requires no maintenance at all.

No configuration or setup effort? No support effort when it doesn't
work? It will add complexity and likely make wire level debugging
techniques obsolete.

---

From: James M Snell <[email-masked]>
Date: Tue, 19 Nov 2013 14:56:53 -0800

Well,  FWIW,  the new binary framing model,  header compression and
multiplexing already make current wire level debugging techniques obsolete.

---

From: David Morris <[email-masked]>
Date: Tue, 19 Nov 2013 15:08:57 -0800 (PST)

> multiplexing already make current wire level debugging techniques obsolete.
	
As I recall there is already a wireshark plugin to take http2 traffic 
apart. In any case, not impossible for a packet sniffer.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 19 Nov 2013 15:11:27 -0800

On Nov 19, 2013, at 2:28 AM, Mike Belshe wrote:
> Again, nobody claimed that TLS would solve all levels of security that anyone on this list can dream up.
> 
> The leap you're making is your conclusion that TLS is not useful as a default option because it doesn't solve every level of security.

No.  Almost every post you make to this list starts with a disclaimer
of broad applicability and then finishes with an even broader claim
about what mandatory TLS will do for the people.  It is tiresome.

What I explained is that the privacy being leaked by plain text HTTP
(that doesn't contain personal data) is not significantly different
from the privacy leaked just by making direct connections to end-points.
What you don't grasp is that most true privacy protection products
work by hiding those direct connections.  There is a reason for that.

> I'm not saying that DNS exposure isn't an issue, but just because we don't solve it with TLS doesn't mean that TLS is bad.

No, it just means that we haven't solved the problem by mandating
TLS.  Maybe directly solving the problem would be better then
causing the entire world to change with little effect.

> Well, cookies are part of HTTP, so....  

Not by my hand.

> But seriously, just encrypt the session, and your cookies get a lot more manageable.  Nothing new needs to be invented - we have this technology right now.

Yeah, like I said ... why should browsers fix actual security holes
when they can insist that everyone else deploy TLS?  Only two of
the above above well-known bugs in browser design, that browsers
claim they cannot possibly fix (because they will lose market share),
would be fixed (indirectly) by sending everything under TLS.

> You're focusing on one level, and ignoring the very real, and now documented threat of widespread and massive data theft at the internet routing points.  

No.  I said don't send the data in plain text if it isn't public.
They can't steal it if the data isn't sent.  If you are sending
personal data, use https links, or other protocols that are
equally secure.

> Despite the grandstanding on here, we all know that TLS is relatively cheap already and getting cheaper every day.  If we standardize around it, and work on tools a little, it'll get even cheaper.  But I don't expect to get agreement on this point.

You don't need agreement on that point.  It has nothing whatsoever
to do with mandating encryption of HTTP/2.  Regardless of what social
requirements we might invent, a considerable number of sites require
strongly authenticated connections, and improving the responsiveness
of those connections should be a priority to everyone.  That doesn't
mean it depends on HTTP/2, in any way, shape, or form.

> One last thing I want to mention is that the downsides of using TLS are a lot less than the downsides of not using TLS.

The immediate downsides of requiring TLS are that it increases the
minimum round trips, the amount of packets needed to send the
same information, and the availability of shared caching.
In other words, it impacts latency and bandwidth, particularly
across shared links (like cross-ocean fiber), for the transfer
of public information.  Primarily, videos of cats.

> As we're all aware, there are about 200 countries on this planet.  Many of the governments of these countries are using packet siphoning as a key information gathering technique.  It's easy today.  They do this for many protocols beyond just HTTP.  But what do they do with this information?  We know the answer to this too - they are out to kill their dissidents.

Umm, no, they use metadata correlation with public postings, which
Google/Facebook/Twitter search and Telco records can provide far
easier than packet siphoning. Few can afford an NSA.

The defense against both is routing activity through anonymizing
services and identities that can't be traced back to a single user agent,
which is something that typical end-to-end TLS actively works against.

I find it painful to watch IETFers feign shock and dismay over
"new" surveillance techniques when those same techniques have
been portrayed in almost every Hollywood movie about the Internet,
for the past fifteen years.  "Enemy of the State" was released in
1998, for crying out loud.

The question at hand is not whether people should use TLS for
securing connections to authenticated services that publish a
verifiable certificate.  The question is whether anyone is *allowed*
to use HTTP/2 while not on a secured connection.  To the extent we
believe such a social requirement would be obeyed in practice,
what effect would it have on adoption of HTTP/2, and on the
Internet as a system?

Regardless, this question doesn't prevent sites from offering
TLS-secured services and providing certificates for that purpose.
I do not need an IETF mandate to use those services because the
site owners were convinced to offer https-only interfaces, and
the reason they were convinced is because the data that they
contain (like social graphs and posting history) is personal.
Education works, particularly when it is backed by regulators and laws.

> So when we don't protect everything from generic siphoning, we are facilitating murders and genocides.  Is this dramatic?  Yeah its dramatic.  But is it untrue?  No.  I know the counter argument already!  You'll say "but we already MITM!", and pretend that MITM is just as easy as siphoning cleartext when we know that its not even close to the same thing. TLS does make raw siphoning of packets orders of magnitude more expensive and difficult to do.  Or you'll say "but DNS is exposed!", as though DNS were on the same level as words and phrases that you communicate with other people.  Or you'll say, "but SMTP is cleartext", as though we have to secure every last possible door if we secure any of them... Sigh.

> I am not sure what the next 10 years will bring.  But I am certain it will bring many incidents where we'll be able to look back and say, "hmmm... if we had put TLS in HTTP by default, that might n…

Absolutely nothing has been revealed in the last 2 years that
wasn't already known during the discussion of SHTTP in 1994.
AFAICT, the only things that have changed are the amount of information,
the rate at which it is sent, the degree of public access to the
Internet, and the overwhelming demand to share too much on social
networks.

Encrypting the channel does not secure the end points.  It certainly
doesn't hide the parties communicating.  Encrypting the message
can allow it to be broadcasted and routed via mechanisms independent
of the original sender.  That can (at least conceptually) anonymize
the sender, but then a few annoying people take advantage of that
feature and abuse the entire commons, such that services need to
add identity requirements just to stay alive, and we are back to
square one.

There are anonymizing services that work.  TLS is not one of them,
though it can certainly be used by them for at least part of the
interaction.  Mail delivery via TLS (along the entire route) makes
sense because all mail messages contain personal data, even spam.
HTTP via TLS isn't necessary because https is always an option.
If you need a header to indicate that, use

   Link: <https://secure.example.com/>; rel="alternate"

> People don't die because we did put in TLS.  They only die if we don't.

*sigh*

I seriously doubt that you have thought through the technical impact
of mandating TLS, let alone understood what effect it would have on
people who depend on anonymity.  What do you think happens when a
user agent is forced to communicate directly to a centralized service
instead of through an intermediary?  What effect does an increase in
round-trip latency, resulting in the desire for maintaining
longer-lived connections and additional state on the client, have
on the ability to identify individual users.  To what degree will
forcing the use of TLS cause sites to mandate user accounts, just
because it is only marginally more disruptive and enables the
provision of more customized user experiences?  How does the
reduced availability of decentrally cached public copies make
it easier to track individual access to that information?

I don't know those answers.  I'd rather let the individuals who
are actually impacted decide, for themselves, which services to use,
and how they wish to use them.

....Roy

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 20 Nov 2013 12:19:46 +1300

On 2013-11-20 11:15, Adrien de Croy wrote:
> free cert providers?  How will they stay in business or the certs
> remain free once the demand for free certs is multiplied by several
> orders of magnitude?

DANE.

* generate your own CA certificate.
* have your DNS provider sign it as part of your DNSSEC signed zone 
records
* profit

Payment (of lack of it) will be part of your contractual agreement with 
DNS provider and avoids the CA authority mess currently blighting trust 
in TLS.

Amos

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 20 Nov 2013 00:24:53 +0000

still not free.  Seems like a bunch of work there.

Certs can therefore no longer be used to provide identity.  Only 
presumably verify admin control over a domain.

But also makes it even easier (at least for us) to MITM, since we are 
also the DNS server for the client, we can alter such records, and then 
we wouldn't even need to deploy a signing cert.

Adrien

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 20 Nov 2013 00:38:21 +0000

also, would DANE spell the end of any URI where the authority is given 
as an IP address rather than a domain name?

that's a lot of links to break.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 20 Nov 2013 00:41:17 +0000

In message <em2e0e431f-78f3-4127-8994-938562a8e560@bodybag>, "Adrien de Croy" w

>It's interesting to play out the scenario from a server vendor

For all practical purposes I am a server vendor.

The fact that Varnish picks contents to deliver via HTTP rather
than NFS is not really material in this context.

Varnish has two nondistinct user-populations:  People who need bits
showelled out fast and people who need to do weird stuff to their
HTML on the way out, sometimes to fix up stuff the backend can't,
but mostly in order to make the shovelling happen even faster.

Typical Varnish bragging right now, is that people shovel 10-30
GBit/sec HTTP per server.

Yes, there are calls for encryption, but people in my user segment
generally see encryption as the antithesis to performance, and they
mainly ask for it, because they think it will be easier to manage
if they have it all in one place.

Four dudes enjoyed a bit of fun at EuroBSDcon on Malta recently.

Representing NetFlix, ManWin, Nginx and Varnish, we are involved
in an awful lot of the HTTP bits on the net, something like every
two out of three bits, the vast majority without any encryption[2].

Needless to say, I don't speak for those other three guys, nor for
that matter do I speak for Varnish users.

My impression is that if we're going to make it hard, procedurally
or politically, to run HTTP/2.0 without the overhead of encryption,
an awful lot of these people will just not bother with HTTP/2.0.

Newspapers and their readers don't care to keep it secret that
they're checking what Miley Did Last Night, and the very few who
do care, will go through TOR.

The Danish Weather Service don't want to waste time and CPU power
authenticating anybody, when half of Denmarks population presses
"Reload" ever few seconds during a storm[1].

Whitehouse.gov *want* people to see the picture of the veggies in
the garden, and if somebody MITM's them, they will deal with it
"out-of-band" so to speak.

And porn sites are all about authenticating the user, not their own
servers, and they certainly don't want the overhead of any crypto
protocol for the actual pink bits.

Cryptography does nothing but hurt these sites business case, and
their users loose no privacy, that's not already surrendered by the
fact that bytes go from IP#1 to IP#2.

If you want to get these sites onboard, it's really very simple:
HTTP/2.0 has to be better for them than HTTP/1.1.

My prediction is that a TLS handshake before first object is unlikely
to be considered "better" and the added CPU load from encrytion is
not going to make anybody happy either.

If you think you can convince them otherwise, be my guest.

On the other hand, if we make a better HTTP/2.0 available on a
dedicated port, so we don't even waste RTTs on some UPGRADE kabuki
dance, a single release of Nginx and Varnish will make a LOT of
HTTP bits available for HTTP/2.0

And in that situation, I don't expect any browser will have necessary
glands to stick to any high horse position about mandating TLS
everywhere:

One does not simply walze away from news and porn.[3]

Poul-Henning

[1] Yes, that is kind of pathetic, but that seems to be what
people do in Denmark during stoms:
	http://www.dmi.dk/nyheder/arkiv/nyheder-2013/10/laeserne-susede-til-dmidk-under-orkanen/

[2] DRM is a different layer and not relevant here.

[3] Hottest thing in hipster-technology: Memes without pictures.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 20 Nov 2013 01:52:44 +0100

>People don't die because we did put in TLS.  They only die if we don't.

Could you give a couple of examples of critical information carried in
HTTP traffic that would become unavailable to such actors if they were
unable to decipher HTTP traffic? It seems reasonable to assume, for in-
stance, that they would be able through one way or another to find out
which IP address was associated with a given target at specific inter-
vals, and asking a couple of large corporations for all data they have
associated with the addresses during those intervals would likely yield
e.g. account identifiers, which could then be used to obtain even more
data. What could these actors want to know that would not be available
through such methods ten years from now?
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 20 Nov 2013 01:17:47 +0000

In message <[email-masked]>

>know the answer to this too - they are out to kill their dissidents.

You need better sources on foreign policy than you currently rely on.

For one thing, Wikipedia only knows of 23 countries which currently
have capital punishment is a legal outcome.

I'm not aware of more than a handful of really uncivilized countries
which can legally kill or even indefinite detain ("life without
parole") people for political crimes.

> But is it untrue?  No.

Yes, very dramatic.

And in fact untrue and unsubstantiated by any evidence I am aware of.

People are in fact not widely persecuted for reading the news or
watching movies or even porn.

Where and when they are, they are almost invariably sentenced on
either independent evidence, usually witnesses or police informers,
or on traffic logs which merely show that packets flowed between their
IP# and the servers IP# on the alleged time and date.

That is not to say that The Global War On Privacy is not a Deep
Shit Situation for us, but unsubstantiated wild-eyed paranoid
pulling-scary-numbers-out-of-my-ass-alarmism is not the way to
confront the problem..

And for reasons already elaborated many times, your solution doesn't
work either.

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 20 Nov 2013 02:23:42 +0100

> from Iran to China to the US, this is widespread.

I'd be interested if anybody knows the ratio of gmail accounts that
were snooped from cleartext vs those snooped on https. And it's
certainly valid for facebook and many other webmails and social
networks used in revolutions.

I'd be inclined to believe that at least some of the ones above do
not provide any clear text access.

So OK you *believe* that doing it your way will make it more difficult
for the snoopers, but it can even be the opposite. If the deployed
technology is 100% focused on TLS right now for whatever reason (eg:
only filters on the SNI to decide if they capture or not), you could
even have it reversed with cleartext passing through undetected.

I'm not saying this is necessary the case, Mike. I'm just saying that
gratuitous claims such as "TLS will raise the bar" are gratuitous,
especially in an era where most useful information already circulates
over TLS and is stolen there (and more commonly inside the browser
because it's the best place for this).

Willy

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 20 Nov 2013 12:25:58 +1100

Gentlemen,

This thread is off-topic for this list, as per <http://www.w3.org/mid/[email-masked]>. Please focus on proposing text for the spec.

Cheers,

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 20 Nov 2013 01:33:50 +0000

ok, so DNSSEC makes it hard to spoof DANE records if the root domain's 
DNSSEC public key is baked into the client.

it however makes the root domain (.) DNSSEC private key the single most 
valuable secret in the history of the world.

What happens if this gets out or gets stolen or brute-forced?

At least CA certs expire, and there are lots of them.  This is seen as a 
negative in the DANE RFC, but it can be a positive in the 
all-eggs-in-one-basket argument.

Sorry if this is O-T, but if we're building the internet on DANE....

------ Original Message ------
From: "Adrien de Croy" <[email-masked]>
To: "Amos Jeffries" <[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 20/11/2013 1:24:53 p.m.
Subject: Re: A proposal
>>Payment (of lack of it) will be part of your contractual agreement 
>>with DNS provider and avoids the CA authority mess currently blighting 
>>trust in TLS.
>>
>>
>>Amos
>>
>>
>
>

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 20 Nov 2013 02:41:10 +0100

On Wed, Nov 20, 2013 at 12:25:58PM +1100, Mark Nottingham wrote:
> Gentlemen,
> 
> This thread is off-topic for this list, as per
> <http://www.w3.org/mid/[email-masked]>. Please
> focus on proposing text for the spec.

You're perfectly right Mark.

And I think that Roy provided a few very very good points. In
order to add some privacy, we need to make it easier and safer
to use proxies.

So let's loop back to one of the very old points about tls+auth for
proxies. This will significantly improve the ability to use anonymisers
and to use them safely. Without even the SNI or destination address
being useful (right now the SNI is carried over clear text even
through proxies).

That way we can have end users safely connect to well known anonymisers
without anyone being able to get anything from that conversation, to
the same extents as what the pro-TLS guys expect from full TLS to
servers.

I know it has been discussed many times in the past, but let's bring
that again on the table so that "people don't die anymore". Secure,
trusted proxies are *the* solution to solve the privacy issues that
make some people insist so much on having TLS. Let's just have it
towards the right place.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 20 Nov 2013 02:43:30 +0100

On Tue, Nov 19, 2013 at 08:00:17PM +0100, Nicolas Mailhot wrote:
> Stop sending referers???

Stop sending pre-connects to recently visited sites when the user starts
the browser and involuntarily shows he's currently online ?

Willy

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 20 Nov 2013 13:07:46 +1100

Hi Willy,

> make some people insist so much on having TLS. Let's just have it

Explicit proxy is tracked here: <https://github.com/http2/http2-spec/issues/316>. 

I've heard a significant amount of interest in this, especially at and after Vancouver, and think we'll see more proposals soon.

Cheers,

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 20 Nov 2013 02:26:56 +0000

proxy discovery could almost deserve its own issue.

A long time ago 305 Use Proxy was deprecated (and apparently it wasn't 
implemented anyway by UA authors).

Personally I think it (or something similar) could have been useful in a 
restricted (trusted) environment to force a browser to use a proxy that 
they weren't going to get anywhere without using.

out of band approaches really are not reliable like a forced 
interception based approach could be.  WPAD is a complete mess, and 
there are so many links in the chain that it's flaky.  An administrator 
has to be coached to

* configure DHCP option 252
* configure DNS
* configure a script file to serve
* configure clients to use auto proxy detection

On the other hand, if a proxy could just intercept port 80, check if the 
request looked like a proxy one or not, if it didn't then bounce with a 
response that got the UA to present a dialog to the user saying 
something like

"the proxy at x.x.x.x asserts that you must use it to access the 
internet, do you wish to proceed"

Then that would be the end of it.  Oviously this could be improved on, 
and maybe it would be a page.  Methods to establish the true origin of 
that requirement could also be put in, to protect against using this 
upstream of the corporate gateway.

Or alternatively this could just trigger the browser to start a proxy 
discovery process.

This would resolve the problem with visiting devices as well.

This issue has been discussed before, but are we the people to deal with 
it?  If it is dealt with in the protocol, then we are.

Adrien

------ Original Message ------
From: "Mark Nottingham" <[email-masked]>
To: "Willy Tarreau" <[email-masked]>
Cc: "HTTP Working Group" <[email-masked]>; "Roy Fielding" 
<[email-masked]>; "Stephen Farrell" <[email-masked]>; 
"Poul-Henning Kamp" <[email-masked]>; "Mike Belshe" 
<[email-masked]>
Sent: 20/11/2013 3:07:46 p.m.
Subject: Explicit Proxy [was: A proposal]
>Explicit proxy is tracked here: 
><https://github.com/http2/http2-spec/issues/316>.
>
>I've heard a significant amount of interest in this, especially at and 
>after Vancouver, and think we'll see more proposals soon.
>
>Cheers,
>
>
>--

---

From: Mike Belshe <[email-masked]>
Date: Tue, 19 Nov 2013 19:23:33 -0800

I wrote up some high level concepts around this in 2011 which may be of
interest:
https://www.belshe.com/2011/11/17/spdy-of-the-future-might-blow-your-mind-today/

I think these are still relevant.

Mike

On Tue, Nov 19, 2013 at 6:07 PM, Mark Nottingham <[email-masked]> wrote:

> Explicit proxy is tracked here: <
> https://github.com/http2/http2-spec/issues/316>.
>

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 20 Nov 2013 08:11:49 +0100

> Explicit proxy is tracked here: <https://github.com/http2/http2-spec/issues/316>. 

Ah yes thanks for the link.

> I've heard a significant amount of interest in this, especially at and after
> Vancouver, and think we'll see more proposals soon.

>From my understanding (I was one of those who insisted on having this),
till now it was mainly to make it easier to transport proxy auth without
revealing credentials and without doing the ugly redirect<->https dance
for the auth. Now I can see this as a solution to solve *the* problem we
identify for users browsing in cleartext, so I think anonymizers is a
new useful feature that should be mentionned there as a way to improve
overall privacy.

Thanks,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 20 Nov 2013 08:15:22 +0100

> I think these are still relevant.

Yes they are. Just like exactly one year earlier I tried to make a mobile
phone operator insist on manufacturers to unlock the explicit proxy config
in smartphones so that they could save the DNS round trip and halve the
overall page load time (since we have many hosts on a page). I remember
there were several discussions about all the benefits for some time and
the explicit proxies were generally received positively by the participants.

Willy

---

From: Yoav Nir <[email-masked]>
Date: Wed, 20 Nov 2013 07:51:25 +0000

> Date: Wed, 20 Nov 2013 02:43:30 +0100
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: A proposal
> 

Why not go whole hog and require a single origin for all resources for everything on a web page?
Oh, yeah. The web would break, but it would sure be sweet for privacy.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 20 Nov 2013 08:03:18 +0000

> From: [email-masked]
> Date: Wed, 20 Nov 2013 13:07:46 +1100
> CC: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
> To: [email-masked]

Hi Mark
To be sure, discovery of proxies may be done at the HTTP layer, but doesn't have to be.  One method to discover TLS proxies is through the TLS handshake. Here's one proposal on how to do it:http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-01
At the time, the TLS working group rejected it, as this was considered to be standardizing wiretap. If this group would like to standardize *any* method of discovering (and cooperating with) TLS proxies, we can resurrect this draft, but expect an up-hill battle with the rest of the IETF, including but not limited to a security AD that is on this list.
Yoav

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 20 Nov 2013 10:29:12 +0100

> they weren't going to get anywhere without using.

A way for proxies to communicate with UAs is certainly required for
explicit proxies to work. And that implies a specific communication stream
with the proxies, to carry prompts, errors, auth, etc in a secure way with
no leakage or spoofing.

305 is universally hated because it's in-stream, so
1. depending on your implementation it does not work with https,
2. or implies breaking TLS,
3. UAs may refuse to display it because of connexion spoofing
4. there is always the risk of leakage if either the intermediary forgets
to remove creds before relaying, or the client sends creds *even when they
are un-needed, just in case* (for example when the client moves to direct
connection)

Also you need some sort of connexion table because on a large private
network you don't want to intercept all traffic just in case something
wants to go outside through the proxy. So anyway you look at it you end up
defining magic dns entries that answer with this connexion table to
provide UAs with this info (though it does not need to be the mess wpad
is). If undefined currently I guess people will just intercept google, and
that will sort of work till search market share changes.

-- 
Nicolas Mailhot

---

From: Roland Zink <[email-masked]>
Date: Wed, 20 Nov 2013 11:30:09 +0100

And to improve second person privacy don't send ETAGs.

Regards,
Roland

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 21 Nov 2013 00:06:22 +0000

------ Original Message ------
>with the proxies, to carry prompts, errors, auth, etc in a secure way 
and also support chained proxies.

I think it would be great if the client could know that a message comes 
from the proxy vs the end server.  I'd also be keen to see progress 
messages.

We did a patch to Chromium to test the http progress ID I suggested a 
long time back.  It actually worked pretty well.  You got progress of 
downloading on the proxy, and AV scanning progress.  The visual 
indication of progress actually happening was very successful in 
preventing users from giving up and refreshing.  If a malware was found, 
you then hadn't sent any payload or even final response yet, so could 
then send a page back with a status relating to the incidence of the 
malware.

>305 is universally hated because it's in-stream, so
actually I think in-stream is potentially a desirable attribute.  You 
can't necessarily guarantee you'll have any other way to talk back to 
the client.

>2. or implies breaking TLS,
yeah https is a problem.

You can't reliably break into an intercepted TLS connection, since you 
don't know if the client has your signing cert installed or not.  In 
most deployments, where MITM is in use, the clients are configured to 
use a proxy, and intercepting a connection from a client is indication 
the client isn't set to use a proxy, and probably isn't set up with the 
cert.

For that you'd need changes to TLS to effect the same thing.

>3. UAs may refuse to display it because of connexion spoofing
you mean the associated address translation?  Sorry I don't follow.  The 
socket won't get the data back unless the source duplet matches.

>to remove creds before relaying,
bug to just fix?

>or the client sends creds *even when they
we see this quite a bit.  In fact there seem to be quite a few clients 
happy to send Proxy-Authorization: Basic ... (empty user/pass) in all 
requests regardless of configuration.  Mostly updaters.  I guess they 
share a broken library.

But I don't see how this affects proxy.  Clients making direct 
connections shouldn't leak proxy creds?

>wants to go outside through the proxy.
That's a network configuration thing.  If an internal router is 
diverting port 80 to the proxy, it should look at the dest IP and not do 
this for intranet sites.

>So anyway you look at it you end up
presuming that connections to google are done at start-up.

Maybe we should just use something to prompt the client to perform 
discovery.  So it would be a 4xx status for http, and something else for 
https.

And something that came up in our support desk today.  To round out the 
discovery feature where you get a client to use a proxy.  It could also 
be useful to have an option to tell a client not to use a proxy (to 
avoid using proxy for intranet for example).  I know this is already 
supported in WPAD, but if the client already connected to the proxy and 
made the request, there's no way to tell the client to connect directly 
instead.

Adrien