Subject: I revised the pro/contra document

From: Tim Bray <[email-masked]>
Date: Sat, 23 Nov 2013 13:15:20 -0800

http://goo.gl/3RtQHP

Thanks to all for the many comments.   I changed all instances of
“encryption” to “privacy or technology” because many pointed out that it’s
not just encryption, it’s encryption and authentication.  Almost all the
other comments were improvements.  I’ll probably publish it as an I-D
unless some more hot comments requiring changes come in. But I think it
documents the controversy in a fairly uncontroversial way.

---

From: Alexandre Anzala-Yamajako <[email-masked]>
Date: Sat, 23 Nov 2013 22:27:16 +0100

I am sorry if these points were discussed before but i don't get why tls isn't appropriate for media files or why we shouldn't secure our connections to printers ?

Cheers

---

From: Mike Bishop <[email-masked]>
Date: Sat, 23 Nov 2013 21:42:44 +0000

Media files often have DRM, which provides encryption at the content layer; it's potentially a waste of resources to re-encrypt content that's already encrypted.  The printers being discussed are intra-home, and care more about ease of setup than providing confidentiality across a fully-controlled network.

-----Original Message-----
From: Alexandre Anzala-Yamajako [mailto:[email-masked]] 
Sent: Saturday, November 23, 2013 1:27 PM
To: Tim Bray
Cc: [email-masked]
Subject: Re: I revised the pro/contra document

Cheers

---

From: Tim Bray <[email-masked]>
Date: Sat, 23 Nov 2013 14:07:21 -0800

I’m just enumerating the arguments that have been expressed a critical-mass
number of times on-list.  I personally think the notion that you don’t need
to encrypt media files is completely wrong, but it has been repeatedly
asserted.

On Sat, Nov 23, 2013 at 1:42 PM, Mike Bishop
<[email-masked]>wrote:

> Media files often have DRM, which provides encryption at the content
> layer; it's potentially a waste of resources to re-encrypt content that's
> already encrypted.  The printers being discussed are intra-home, and care
> more about ease of setup than providing confidentiality across a
> fully-controlled network.
>
> I am sorry if these points were discussed before but i don't get why tls
> isn't appropriate for media files or why we shouldn't secure our
> connections to printers ?
>
> Cheers
>

---

From: Mike Belshe <[email-masked]>
Date: Sat, 23 Nov 2013 14:53:38 -0800

Alexandre -

Your question is a reasonable one.  And personally, I agree with Tim, that
TLS is useful for all data transmitted over HTTP.

In the case of printers, TLS is absolutely suitable, and in fact employed
today at most fortune-500 companies.  Imagine employees being able to snoop
insider information as it flows over wifi to the printers?  Corporate IT
guys long ago fixed this problem.  Even for home use, do you want your
neighbor to steal your taxes as you print them?

For media content, TLS is also appropriate.

Mike Bishop brought up the DRM case, which is fine, but somewhat orthogonal
to HTTP.  You see, DRM is protecting *data at rest* (e.g. stored on a disk
somewhere) rather than *data-in-motion* (e.g. being transmitted over HTTP.
 There are many interesting facets to data-at-rest protections.  But they
out of scope for HTTP.  HTTP is a transport protocol and only deals with
data-in-motion.   It is worth elaborating on Mike's example, however,
because he didn't mention that transmitting the DRM-protected data over
HTTP contains metadata (e.g. the name of the video, keywords, authors,
people, links, etc) which can also be sensitive itself.  Should your
neighbor know that you're watching porn right now?  Should your neighbor
know that you're researching <insert sensitive topic here>?  When
discussing HTTP, we should be talking about data in motion only, and even
encoded content, like DRM content still benefits from TLS.

Ok, so when it comes to data in motion, how do we decide if TLS is useful?

First let's consider which parties are involved in a HTTP transaction.
 There are:
    a) the user
    b) the server
    c) the middleware in between

The user, of course, expects his data to be sent privately.  We don't want
random others to view our communications.  The only downside would be if
there were side effects to transmitting privately.  For instance, if my
network were slower, or it cost more, etc - some users would be willing to
exchange private communications for lower cost.  However, those of us that
have researched TLS in depth know that it can be deployed at near zero cost
today.  This is contentious on this list.  But as we look forward, with
computer speeds increasing and the Internet growing larger, it is clear
that any cost of TLS will only get cheaper.  As a second counter argument,
some on this list observe that some users that employ proxies to help
filter malware over their unencrypted streams.  This is still possible with
TLS, you just need to move to a Trusted Proxy that uses TLS as well.  And
of course, virus writers have already figured this out too.  They're
starting to use TLS because they know these users can't currently detect
viruses over encrypted channels.  So regardless of whether you like HTTP
using TLS all the time, we still need Trusted Proxies for our TLS.  It's
just an independent issue.

The server, unfortunately, can't tell whether TLS is appropriate or not,
because the need for privacy depends on the user.   As an example, we
discussed the case where a user is downloading public information about a
disease.  If the user is a medical student studying for an exam, it's
probably okay in the clear.  But that exact information, when sent to a
patient for a real case, suddenly *does* need to be transmitted privately.
 Using TLS all the time has no negative issue, while using TLS some of the
time does.  To solve this for their users, servers should always use TLS.

Finally, we can discuss the middleware.  Nobody knows exactly how much
middleware exists between a user and a server.   As noted, we could use
non-authenticated encryption (non-TLS, or unverified TLS), which would at
least make it more difficult for passive middleware to decode the traffic
running through it.  However, using authenticated encryption (what TLS
already does) eliminates passive snooping, and also makes it quite
difficult to snoop without detection.  Although those on this list like to
say that "MITM" is everywhere, MITM is usually discoverable, and none of
the off-the-shelf MITM solutions today can employ MITM with complete
invisibility.  Using TLS today would eliminate all but the most
sophisticated attacks by middleware stealing our data in motion.

So, to answer your question, of are media files and printers well suited
for TLS?   Yes, of course!

Mike

On Sat, Nov 23, 2013 at 2:07 PM, Tim Bray <[email-masked]> wrote:

> I’m just enumerating the arguments that have been expressed a
> critical-mass number of times on-list.  I personally think the notion that
> you don’t need to encrypt media files is completely wrong, but it has been
> repeatedly asserted.
>
>
> On Sat, Nov 23, 2013 at 1:42 PM, Mike Bishop <[email-masked]
> > wrote:
>

---

From: Michael Sweet <[email-masked]>
Date: Sat, 23 Nov 2013 19:01:08 -0500

Alexandre,

There is a processing overhead associated with encryption - I've seen up to a 40% speed penalty for printers, for example. When applied to streaming of large files like movies (which already have their own layer of protections), that generally means the provider needs more servers with hardware accelerated TLS, and similarly more processing needs to be done on each client which may limit the quality/quantity of video that can be played. And imagine the increased power usage - not the direction most people are trying to go...

Aside from the basic resource issues, consider printing again. Most printers are not used in environments that need encryption. Those that do often do not have stable addresses or host names, making authentication and certificate management a greater challenge. So for printers I have personally fought hard for all TLS support but not necessarily to enable it by default. 

Sent from my iPad

> On Nov 23, 2013, at 4:27 PM, Alexandre Anzala-Yamajako <[email-masked]> wrote:
>

---

From: Mike Belshe <[email-masked]>
Date: Sat, 23 Nov 2013 17:12:33 -0800

On Sat, Nov 23, 2013 at 4:01 PM, Michael Sweet <[email-masked]> wrote:

> Alexandre,
>
> There is a processing overhead associated with encryption - I've seen up
> to a 40% speed penalty for printers, for example. When applied to streaming
> of large files like movies (which already have their own layer of
> protections), that generally means the provider needs more servers with
> hardware accelerated TLS, and similarly more processing needs to be done on
> each client which may limit the quality/quantity of video that can be
> played. And imagine the increased power usage - not the direction most
> people are trying to go...
>

Do you have any benchmarks on this?  Or a breakdown of printers print that
slowly?  Are these modern printers or old ones?

If a typical printer is printing 10ppm, we need to keep the flow of a page
of data per 6 seconds.  In 6 seconds, you can do a lot of computing and
transmit a boatload of bits, even on a modest printer.  I know that
printers use small and sometimes memory constrained CPUs, but given the
slowness of actually printing a page, I have a hard time believing that TLS
can't keep up most of the time.  I also wouldn't be surprised if the
failure here was implementation quality rather than TLS itself.

So before we throw TLS under the bus for all of the internet in order to
save what may be a tiny segment of printers (that can still use HTTP/1.1 if
they want to!), I think we should quantify this problem with real data.

For what it is worth, despite my skepticism about the 40% number, I'd still
rather prefer safe data transmission and a 40% print speed loss than have
my data stolen by the guy sitting next to me at kinko's.

Mike

>
> Aside from the basic resource issues, consider printing again. Most
> printers are not used in environments that need encryption. Those that do
> often do not have stable addresses or host names, making authentication and
> certificate management a greater challenge. So for printers I have
> personally fought hard for all TLS support but not necessarily to enable it
> by default.
>
> Sent from my iPad
>

---

From: Matthew Kerwin <[email-masked]>
Date: Sun, 24 Nov 2013 14:40:04 +1000

On 24 November 2013 11:12, Mike Belshe <[email-masked]> wrote:

>
>  (that can still use HTTP/1.1 if they want to!)
>
>
I have to chime in here.  I keep seeing this point mentioned on the list.
 This is not a valid counterpoint, or a justification for adding something
to HTTP/2, or an excuse for ignoring someone's use-case for HTTP.  If
anybody chooses HTTP/1.1 over HTTP/2 for _any reason_ other than laziness
or stubborn change aversion, then HTTP/2 has failed in its primary purpose.

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: James M Snell <[email-masked]>
Date: Sat, 23 Nov 2013 20:53:21 -0800

+1... The "they can just use 1.1" argument is getting rather tiresome.

---

From: Tim Bray <[email-masked]>
Date: Sat, 23 Nov 2013 21:33:42 -0800

Unconvinced. Life is full of trade-offs. Enhancing HTTP/2's privacy story
is not without costs. When balancing costs and benefits, it's reasonable to
consider that the costs may be mitigated by the continuing availability of
HTTP/1.1. It's not axiomatic that HTTP/2 has to be the single best choice
in all situations, in order to be a success.

---

From: James M Snell <[email-masked]>
Date: Sat, 23 Nov 2013 21:41:13 -0800

Yes, but the "they can just use 1.1" argument is being used consistently to
justify design choices for 2.0. That's just wrong.

---

From: Tim Bray <[email-masked]>
Date: Sat, 23 Nov 2013 23:08:15 -0800

Actually, it’s being used repeatedly to defend one specific design option
for HTTP/2: Strong privacy requirements.  The benefits of this seem high.
And the costs are arguably quite bearable given that anyone who can’t pay
them has the free HTTP/1.1 option.

On Sat, Nov 23, 2013 at 9:41 PM, James M Snell <[email-masked]> wrote:

> Yes, but the "they can just use 1.1" argument is being used consistently
> to justify design choices for 2.0. That's just wrong.
>>> I have to chime in here.  I keep seeing this point mentioned on the
>>> list.  This is not a valid counterpoint, or a justification for adding
>>> something to HTTP/2, or an excuse for ignoring someone's use-case for HTTP.
>>>  If anybody chooses HTTP/1.1 over HTTP/2 for _any reason_ other than
>>> laziness or stubborn change aversion, then HTTP/2 has failed in its primary
>>> purpose.
>>>
>>> --
>>>   Matthew Kerwin

---

From: Mike Belshe <[email-masked]>
Date: Sat, 23 Nov 2013 23:15:34 -0800

> or stubborn change aversion, then HTTP/2 has failed in its primary purpose.

At its limits, this can't be true, because what you're saying is if one
dude at the Computer History Museum of Timbuktu says he can't get HTTP/2 to
work on his PDP-11 because of crypto laws unique to his religious beliefs,
then HTTP/2 has failed.

The problem with not having an escape valve for minority use cases is that
anyone can hold up the entire effort by saying "I wouldn't use that for my
xyz use case".

I assure you that there is no form of HTTP/2, TLS or otherwise that will
satisfy everyone.  I'm happy to debate what the merits are for when this
escape hatch of 'just use http/1.1' is valid and when it is not, but what
you're saying is simply impractical.

Mike

---

From: Mike Belshe <[email-masked]>
Date: Sat, 23 Nov 2013 23:22:44 -0800

> to justify design choices for 2.0. That's just wrong.
I guess what I'm saying here is that yes, if you have an old device that
really can't handle TLS (and given that TLS runs on some pretty modest
devices, I'm skeptical), you can use HTTP/1.1.  It's not a big deal.  If
you're so constrained that you can't handle TLS, then you probably aren't
going to see much benefit from the other aspects of HTTP/2.0 either.

But I don't want to hold up progress on HTTP/2.0 for everyone because of a
very minority claim that legacy hardware performance is bad.

Anyway, I think the summary I put forth above had a lot more meat to it
than this minor, parenthetical comment about HTTP/1.1.  It might be more
fruitful to discuss that.

Mike

---

From: Yoav Nir <[email-masked]>
Date: Sun, 24 Nov 2013 11:00:45 +0200

On 24/11/13 12:53 AM, Mike Belshe wrote:
> Alexandre -
>
> Your question is a reasonable one.  And personally, I agree with Tim, 
> that TLS is useful for all data transmitted over HTTP.
>
> In the case of printers, TLS is absolutely suitable, and in fact 
> employed today at most fortune-500 companies.  Imagine employees being 
> able to snoop insider information as it flows over wifi to the 
> printers?  Corporate IT guys long ago fixed this problem.  Even for 
> home use, do you want your neighbor to steal your taxes as you print them?
My home does not have the IT department of a Fortune 500 company. I'm 
sort of a techie guy, so I can probably figure out the web interface of 
a network-attached printer. But how can I get a certificate for my 
printer? I know you believe that the tools will magically appear to make 
certificate management easy. But if the numbers stated are correct, that 
30% of websites already have valid certificates, then the growth of 
HTTPS will not be enough to make tools where none existed before.
> Mike Bishop brought up the DRM case, which is fine, but somewhat 
> orthogonal to HTTP.  You see, DRM is protecting /data at rest/ (e.g. 
> stored on a disk somewhere) rather than /data-in-motion/ (e.g. being 
> transmitted over HTTP.  There are many interesting facets to 
> data-at-rest protections.  But they out of scope for HTTP.  HTTP is a 
> transport protocol and only deals with data-in-motion.   It is worth 
> elaborating on Mike's example, however, because he didn't mention that 
> transmitting the DRM-protected data over HTTP contains metadata (e.g. 
> the name of the video, keywords, authors, people, links, etc) which 
> can also be sensitive itself.  Should your neighbor know that you're 
> watching porn right now?  Should your neighbor know that you're 
> researching <insert sensitive topic here>?  When discussing HTTP, we 
> should be talking about data in motion only, and even encoded content, 
> like DRM content still benefits from TLS.
>
> The user, of course, expects his data to be sent privately.  We don't 
> want random others to view our communications.  The only downside 
> would be if there were side effects to transmitting privately.  For 
> instance, if my network were slower, or it cost more, etc - some users 
> would be willing to exchange private communications for lower cost. 
>  However, those of us that have researched TLS in depth know that it 
> can be deployed at near zero cost today.  This is contentious on this 
> list.
It's not contentious, it's just false. Go to the pricing page for Amazon 
cloundfront CDN <http://aws.amazon.com/cloudfront/#pricing> (I would 
have picked Akamai, but they don't put pricing on their website), and 
you pay 33% more plus a special fee for the certificate for using HTTPS. 
That's pretty much in line with the 40% figure. That's real cost that 
everybody has to bear. And you will get similar numbers if you host your 
site on your own servers.
> But as we look forward, with computer speeds increasing and the 
> Internet growing larger, it is clear that any cost of TLS will only 
> get cheaper.
Right along with the price of serving plaintext HTTP. That is also 
getting cheaper.
>  As a second counter argument, some on this list observe that some 
> users that employ proxies to help filter malware over their 
> unencrypted streams.  This is still possible with TLS, you just need 
> to move to a Trusted Proxy that uses TLS as well.  And of course, 
> virus writers have already figured this out too.  They're starting to 
> use TLS because they know these users can't currently detect viruses 
> over encrypted channels.  So regardless of whether you like HTTP using 
> TLS all the time, we still need Trusted Proxies for our TLS.  It's 
All true, but I don't see how that is a counter-argument. HTTPS 
inspection is more expensive than HTTP inspection, and requires more 
user inconvenience.
>
> The server, unfortunately, can't tell whether TLS is appropriate or 
> not, because the need for privacy depends on the user.   As an 
> example, we discussed the case where a user is downloading public 
> information about a disease.  If the user is a medical student 
> studying for an exam, it's probably okay in the clear.  But that exact 
> information, when sent to a patient for a real case, suddenly *does* 
> need to be transmitted privately.  Using TLS all the time has no 
> negative issue, while using TLS some of the time does.  To solve this 
> for their users, servers should always use TLS.
There are many examples we can think of, but the question of whether 
information is sensitive depends on many factors, and it's not 
necessarily always true that the requirement for privacy comes from the 
client side of TCP. A good TLS proxy solution would have to allow both 
client and server to veto non-E2E encryption.
> middleware exists between a user and a server.   As noted, we could 
> use non-authenticated encryption (non-TLS, or unverified TLS), which 
> would at least make it more difficult for passive middleware to decode 
> the traffic running through it.  However, using authenticated 
> encryption (what TLS already does) eliminates passive snooping, and 
> also makes it quite difficult to snoop without detection.  Although 
> those on this list like to say that "MITM" is everywhere, MITM is 
> usually discoverable, and none of the off-the-shelf MITM solutions 
> today can employ MITM with complete invisibility.  Using TLS today 
> would eliminate all but the most sophisticated attacks by middleware 
> stealing our data in motion.
>
> So, to answer your question, of are media files and printers well 
> suited for TLS?   Yes, of course!
Great! How do I get some?

Yoav

---

From: Mike Belshe <[email-masked]>
Date: Sun, 24 Nov 2013 02:05:53 -0800

On Sun, Nov 24, 2013 at 1:00 AM, Yoav Nir <[email-masked]> wrote:

> employed today at most fortune-500 companies.  Imagine employees being able
> to snoop insider information as it flows over wifi to the printers?
>  Corporate IT guys long ago fixed this problem.  Even for home use, do you
> want your neighbor to steal your taxes as you print them?
>
> My home does not have the IT department of a Fortune 500 company. I'm sort
> of a techie guy, so I can probably figure out the web interface of a
> network-attached printer. But how can I get a certificate for my printer? I
> know you believe that the tools will magically appear to make certificate
> management easy. But if the numbers stated are correct, that 30% of
> websites already have valid certificates, then the growth of HTTPS will not
> be enough to make tools where none existed before.
>

I doubt you would bother to install a valid certificate; you'd just use a
self-signed cert or something, and because you've said you don't care about
it, you'd ignore the warnings.

> orthogonal to HTTP.  You see, DRM is protecting *data at rest* (e.g.
> stored on a disk somewhere) rather than *data-in-motion* (e.g. being
> transmitted over HTTP.  There are many interesting facets to data-at-rest
> protections.  But they out of scope for HTTP.  HTTP is a transport protocol
> and only deals with data-in-motion.   It is worth elaborating on Mike's
> example, however, because he didn't mention that transmitting the
> DRM-protected data over HTTP contains metadata (e.g. the name of the video,
> keywords, authors, people, links, etc) which can also be sensitive itself.
>  Should your neighbor know that you're watching porn right now?  Should
> your neighbor know that you're researching <insert sensitive topic here>?
>  When discussing HTTP, we should be talking about data in motion only, and
> even encoded content, like DRM content still benefits from TLS.
>
> want random others to view our communications.  The only downside would be
> if there were side effects to transmitting privately.  For instance, if my
> today.  This is contentious on this list.
>
> cloundfront CDN <http://aws.amazon.com/cloudfront/#pricing> (I would have
> picked Akamai, but they don't put pricing on their website), and you pay
> 33% more plus a special fee for the certificate for using HTTPS. That's
> pretty much in line with the 40% figure. That's real cost that everybody
> has to bear. And you will get similar numbers if you host your site on your
> own servers.
>

I think you're thinking like an engineer.  You're right, they do charge
more (and I'm right those prices will continue to come down).  But those
prices are already TINY.  I know 33% sounds like a lot, but this is not the
primary cost of operating a business.  So if you want to do a price
comparison, do an all-in price comparison.  And you'll find that the cost
of TLS is less than a fraction of a percent difference in operating cost
for most businesses.

And if you're not talking about businesses, but consumers, CDNs aren't
really relevant.  As an example, I run my home site at Amazon for zero
extra cost, but I did buy a 5yr $50 cert.

>
>  But as we look forward, with computer speeds increasing and the Internet
> growing larger, it is clear that any cost of TLS will only get cheaper.
>
> Right along with the price of serving plaintext HTTP. That is also getting
> cheaper.
>

agree

>
>   As a second counter argument, some on this list observe that some users
> that employ proxies to help filter malware over their unencrypted streams.
>  This is still possible with TLS, you just need to move to a Trusted Proxy
> that uses TLS as well.  And of course, virus writers have already figured
> this out too.  They're starting to use TLS because they know these users
> can't currently detect viruses over encrypted channels.  So regardless of
> whether you like HTTP using TLS all the time, we still need Trusted Proxies
> for our TLS.  It's just an independent issue.
>
> All true, but I don't see how that is a counter-argument. HTTPS inspection
> is more expensive than HTTP inspection, and requires more user
> inconvenience.
>

My point is that if you're interested in filtering, you already have to do
HTTPS inspection today.  And that is the real driver for why companies are
employing those solutions.   So this is not relevant as we decide how to
use TLS in HTTP/2.

> information is sensitive depends on many factors, and it's not necessarily
> always true that the requirement for privacy comes from the client side of
> TCP. A good TLS proxy solution would have to allow both client and server
> to veto non-E2E encryption.
>

I'd like to hear an example where the user requested a secure channel and
the server should have the right to veto.  Why would either endpoint want
to, actually?  Only middleware that wants to insert itself ever wants to do
that.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 24 Nov 2013 14:15:34 +0000

A general point - *please* don't talk about adding "privacy"
to HTTP - we're discussing confidentiality and server-auth.
Making confidentiality or both be the default for HTTP/2.0
will be a wonderful thing IMO. But the end result of doing
that is just not "privacy" and folks sloppily arguing that
you do get privacy as a result are just damaging the argument
to get confidentiality by default.

> it, you'd ignore the warnings.

First Yoav is entirely correct that getting a certificate that chains
up to a browser-trusted root is not doable for printers except within
enterprises that install their own roots into employee browsers. That
nicely shows up the benefit of the http:// URI via opportunistic TLS
in HTTP/2.0 approach again. That's the approach we should take. It
needs no new PKI tooling or admin to solve a problem that we have
repeatedly failed to solve over the last 20 years. The "problem" I
mean there is a PKI enrollment setup that just works well everywhere.
There isn't one. Not unless you completely re-do the CA business
model. And assuming that would not be a good thing when designing
HTTP/2.0. (The CA business model will evolve sure, and maybe in a
good direction, but we cannot assume that.)

I find Mike's response very odd. Browsers have been adding UI to make
SSC's (self-signed certs) less usable for years. Now that's not an
easy thing to get right, since there are many web sites (e.g. one of
mine [1]) that use SSCs for reasonable purposes, but once you have
users accepting SSCs (as studies show does happen) then the
server-auth aspect of TLS is damaged. (In the case of [1] I'm fine
that it cause browser barfs since I use that to mess with students'
heads. And I did have a good reason to turn on confidentiality
since I used to host some kids-football-team contact info there.
I just have never had a good enough reason to deal with a real PKI
for it.)

   [1] https://down.dsg.cs.tcd.ie/

>>  Ok, so when it comes to data in motion, how do we decide if TLS is

Here, Mike is entirely correct. The network stack cannot know when
the payload or meta-data are sensitive so the only approach that
makes sense is to encrypt the lot to the extent that that is practical.
Snowdonia should be evidence enough for that approach even for those
who previously doubted pervasive monitoring.

HTTP is used for lots of sensitive data all the time in places that
don't use https:// URIs today. Sensitive data doesn't require any
life or death argument, it can be nicely mundane, e.g. a doctor
visit being the example Alissa used in the plenary in Vancouver.

We now can, and just should, fix that. There's no hyperbole needed
to make that argument compelling.

> extra cost, but I did buy a 5yr $50 cert.

So if HTTP/2.0 uses TLS by default then the relevant difference
will be between HTTP/2.0 and HTTP/1.1 without TLS, right?

If this wg does a good job on the overall efficiency of the
protocol then I can't see any good reason why a cloudy provider
wouldn't be able to offer the same pricing for HTTP/2.0 and
cleartext HTTP/1.1 (other than having to pay a CA, but then I
don't think we should require that). And that's about as much
as should concern us here I think.

>> Right along with the price of serving plaintext HTTP. That is also getting

Disagree. The costs of moving the bits around in clear will get
cheaper. But the risk associated with doing that is getting high
enough that e.g. /. today tells me [2] twitter turned on ECDH with
PFS. Plaintext is not really cheaper once there's a significant
enough adversary.

   [2]
http://techcrunch.com/2013/11/22/twitter-enables-perfect-forward-secrecy-across-sites-to-protect-user-data-against-future-decryption/

> employing those solutions.   So this is not relevant as we decide how to

This wg should IMO not even consider the requirements for such MITM
attack boxes. (Except as a threat.) And the term "trusted proxy" is
pure BS. (I'm not sorry for being blunt there, but apologies if my
bluntness offends.) I've never seen an acceptable technical solution
in any of the proposals that have been made for MITM attack boxes.
And that's ignoring RFC 2804, and what I hope will be a new RFC on
that topic resulting from Vancouver. [3]

   [3] http://tools.ietf.org/html/draft-farrell-perpass-attack

I do think the wg should consider HTTP proxies and how those work
with HTTP/2.0. That is where you should consider requirements for
HTTP filtering or scanning. And if that requires a less efficient
use of HTTP/2.0 (e.g. I think it'll need two TLS sessions and some
new browser config and/or of leap-of-faith processing in the
browser) then so be it.

But starting from an approach that assumes you can break TLS to
solve an HTTP problem would be sheer folly. Its been tried and
failed. If its tried again it'll fail again.

Cheers,
S.

---

From: Michael Sweet <[email-masked]>
Date: Sun, 24 Nov 2013 14:16:09 -0500

Mike,

> On Nov 23, 2013, at 8:12 PM, Mike Belshe <[email-masked]> wrote:
> 
> Do you have any benchmarks on this?  Or a breakdown of printers print that slowly?  Are these modern printers or old ones? 

Brand new consumer/SOHO printers. The impact is less on enterprise office equipment, and there are some mid-range printers with PDF support that, while they don't do TLS any faster they have less data to move. I am actually working on a white paper to summarize the results.

> If a typical printer is printing 10ppm, we need to keep the flow of a page of data per 6 seconds.  In 6 seconds, you can do a lot of computing and transmit a boatload of bits, even on a modest printer.

Consider that you are pumping 100MB of raster data per page for a typical consumer/SOHO printer. With compression you can get that down to about 1/5th of that on average (better for text, worse for photos). So figure 3.4MB/sec.

Most printers in this class use microcontroller/SoC implementations that are hard pressed to maintain that data rate. Add a software TLS implementation and they just don't keep up.

>  I know that printers use small and sometimes memory constrained CPUs, but given the slowness of actually printing a page, I have a hard time believing that TLS can't keep up most of the time.  I also wouldn't be surprised if the failure here was implementation quality rather than TLS itself.  

There is an overhead in TLS, even for "good" implementations. It doesn't come for free.

> So before we throw TLS under the bus for all of the internet in order to save what may be a tiny segment of printers (that can still use HTTP/1.1 if they want to!), I think we should quantify this problem with real data.
> 
> For what it is worth, despite my skepticism about the 40% number, I'd still rather prefer safe data transmission and a 40% print speed loss than have my data stolen by the guy sitting next to me at kinko's.

And clearly printing at kinkos is different than printing at home or printing in an office.

Today you'll find many printers that support TLS but none that enable it out of the box. Most have a button or menu item to turn it on, which generates a self signed certificate. And most also allow you to upload "real" certs. You, as the customer/user/owner get to decide whether to use it or not...

---

From: Mike Belshe <[email-masked]>
Date: Sun, 24 Nov 2013 11:15:48 -0800

> to get confidentiality by default.

You are correct:  s/privacy/confidentiality/

> able
> sort

Well, really, I was avoiding the 'just use http/1.1' argument.  But there
are a number of ways to deal with the use case.

> data-at-rest
> have
> Internet
> getting

excellent point.

> users
> inspection

what i'm referring to here is the current MITM solutions people are rolling
out already.  Although you may not think these are 'acceptable technical
solutions', it is clear that industry disagrees with you because they're
getting rolled out commonly.  I don't like them either, and I think we can
do better if browsers play an explicit role (like what you alluded to
later).

What I was getting at is that there has been a steady argument against
using TLS in HTTP/2 because it will cause everyone to "go implement MITM".
 It is true that companies are rolling out MITM already because of
increased TLS usage.  What isn't true is that HTTP/2 will be the cause of
it.

So lets not get caught up in the term 'trusted proxy'.  The facts we need
to accept are that MITM rollouts do happen already, that HTTP/2
(independent of its TLS requirements) could define new proxy hooks/behavior
that would alleviate this, and that MITM will happen even if we don't add
TLS to HTTP/2.

> failed. If its tried again it'll fail again.

You're not being practical.  If we don't make it work explicitly, companies
are going to roll it out with MITM anyway.  They care more about IP
protection than the additional risk they take on by breaking the TLS stream.

Mike

> not,
> necessarily

---

From: Zhong Yu <[email-masked]>
Date: Sun, 24 Nov 2013 13:21:29 -0600

> guys long ago fixed this problem.  Even for home use, do you want your

If the problem has been fixed, and presumably nobody can sniff any
bits sent by others, regardless of protocol, why is it still necessary
to encrypt traffic to printers?

> neighbor to steal your taxes as you print them?

If my neighbors can sniff my network traffic, I got a huge problem,
and solution is not to encrypt my data to my printer.

> to HTTP.  You see, DRM is protecting data at rest (e.g. stored on a disk
> somewhere) rather than data-in-motion (e.g. being transmitted over HTTP.
> There are many interesting facets to data-at-rest protections.  But they out
> of scope for HTTP.  HTTP is a transport protocol and only deals with
> because he didn't mention that transmitting the DRM-protected data over HTTP
> contains metadata (e.g. the name of the video, keywords, authors, people,
> links, etc) which can also be sensitive itself.  Should your neighbor know
> that you're watching porn right now?  Should your neighbor know that you're
> researching <insert sensitive topic here>?  When discussing HTTP, we should
> be talking about data in motion only, and even encoded content, like DRM
> content still benefits from TLS.
>
> computer speeds increasing and the Internet growing larger, it is clear that
> any cost of TLS will only get cheaper.  As a second counter argument, some
> on this list observe that some users that employ proxies to help filter
> malware over their unencrypted streams.  This is still possible with TLS,
> you just need to move to a Trusted Proxy that uses TLS as well.  And of
> course, virus writers have already figured this out too.  They're starting
> to use TLS because they know these users can't currently detect viruses over
> encrypted channels.  So regardless of whether you like HTTP using TLS all
> the time, we still need Trusted Proxies for our TLS.  It's just an
> independent issue.
>
> already does) eliminates passive snooping, and also makes it quite difficult
> to snoop without detection.  Although those on this list like to say that
> "MITM" is everywhere, MITM is usually discoverable, and none of the
> off-the-shelf MITM solutions today can employ MITM with complete
> So, to answer your question, of are media files and printers well suited for
> TLS?   Yes, of course!
>
> Mike
>
>
>
>
>> <[email-masked]> wrote:
>>>
>>> isn't appropriate for media files or why we shouldn't secure our connections
>>> to printers ?
>>>
>>> Cheers
>>
>>
>

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 24 Nov 2013 19:27:11 +0000

> protection than the additional risk they take on by breaking the TLS stream.

Please see my earlier mail on how many other things would
be broken should we stupidly break TLS for this. [1] And
then go ask all those other folks who depend on TLS what
they think is practical.

As I've said, doing HTTP scanning or filtering *in* HTTP
seems reasonable in some cases. Breaking TLS to meet that
requirement does not. And breaking TLS is just not needed
if real work on proxies gets done, but I don't know if the
WG will do that or not.

S.

[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0906.html

---

From: Zhong Yu <[email-masked]>
Date: Sun, 24 Nov 2013 13:27:50 -0600

What I hear is:
A: here's why encryption is a pro for http2
B: here's why encryption is a con for http2
A: well you can use http1, so encryption is not a con for http2.

On Sat, Nov 23, 2013 at 11:33 PM, Tim Bray <[email-masked]> wrote:
> Unconvinced. Life is full of trade-offs. Enhancing HTTP/2's privacy story is
> not without costs. When balancing costs and benefits, it's reasonable to
> HTTP/1.1. It's not axiomatic that HTTP/2 has to be the single best choice in
> all situations, in order to be a success.
>
>> This is not a valid counterpoint, or a justification for adding something to
>> HTTP/2, or an excuse for ignoring someone's use-case for HTTP.  If anybody
>> chooses HTTP/1.1 over HTTP/2 for _any reason_ other than laziness or
>> stubborn change aversion, then HTTP/2 has failed in its primary purpose.
>>
>> --
>>   Matthew Kerwin

---

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

Hi Stephen

it's not clear to me in your last para about attack proxies.

Are you saying that we should only be able to scan http, and not https?

Or that we need to fix things so we can scan https without

a) breaking TLS
b) deploying MITM.

Adrien

------ Original Message ------
From: "Stephen Farrell" <[email-masked]>
To: "Mike Belshe" <[email-masked]>; "Yoav Nir" <[email-masked]>
Cc: "Tim Bray" <[email-masked]>; "Mike Bishop" 
<[email-masked]>; "Alexandre Anzala-Yamajako" 
<[email-masked]>; "[email-masked]" <[email-masked]>
Sent: 25/11/2013 3:15:34 a.m.
Subject: Re: I revised the pro/contra document
>>>would be
>>>use

---

From: "Adrien de Croy" <[email-masked]>
Date: Sun, 24 Nov 2013 20:10:55 +0000

------ Original Message ------
>if real work on proxies gets done, but I don't know if the
I think the HTTP needs to do a lot better job wrt proxying.

Support for proxies in http/1.x is pretty half-arsed sorry to be blunt.  
   A couple of headers.  And the thing we all rely on (using GET 
http://authority.... vs GET /something) only works because no browser 
actually uses the fully qualified form of the request URI which is 
specified in 2616 except when talking to a proxy (thank goodness).

We're designing a protocol here, everything should be deterministic.  We 
shouldn't need to do guessing about what is the target for some proxy 
credentials, or whether a client thinks it's talking to a proxy or not.

In HTTP/2.0 I'd like to see explicit support in the protocol for 
interactions between client and a proxy.  And it would be useful to 
handle chained proxies.  We occasionally get requests where people want 
to pass creds through to an upstream proxy of their proxy.

And even though this has been raised and dumped before, I think it's 
foolhardy to continue to ignore the existence of intercepted 
connections.  Until we get some decent mechanism to force a client to 
use a proxy, we're going to get interception.

Adrien

>
>S.
>
>[1] 
>http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0906.html
>

---

From: Roland Zink <[email-masked]>
Date: Sun, 24 Nov 2013 22:10:48 +0100

Encryption doesn't come for free. It costs energy even when the hardware 
is able to do the encryption. When it is unnecessary this should be avoided.

Regards,
Roland

---

From: Matthew Kerwin <[email-masked]>
Date: Mon, 25 Nov 2013 07:39:49 +1000

> to make that argument compelling.
This smells like scope creep.  Maybe I just need clarification of the
charter: are we here to fix the web, or define a new-and-improved HTTP
protocol?

My dream is a minimal-pain swap-in replacement for HTTP/1.1, that makes
everything faster and better.  The roadblock to that seems to be cruddy old
proxies which will break the flow, but all this argument about people who
don't encrypt details about their doctor's visits doesn't actually compel
me at all.  If the only way to get HTTP/2 to work on the web today is to
stuff it all down a pipe that the cruddy proxies will pass without
breaking, then fine, use TLS; but I'd suggest we not write that in the
HTTP/2 spec, it's a (transient?) detail of the current state of the web.

---

From: Tim Bray <[email-masked]>
Date: Sun, 24 Nov 2013 18:55:39 -0800

I’m not understanding why you're objecting to the use of the word
”privacy”.  It’s not a binary condition, and effective deployment of
encryption and authentication technologies increase the degree of effective
privacy for users of the Internet. Why not say so?

---

From: Eliot Lear <[email-masked]>
Date: Mon, 25 Nov 2013 07:39:18 +0100

Tim,

On 11/23/13 11:07 PM, Tim Bray wrote:
> critical-mass number of times on-list.  I personally think the notion
> that you don’t need to encrypt media files is completely wrong, but it
> has been repeatedly asserted.

The point is- this is other people's money you're talking about. 
Consider a large producer of such media content who derives no benefit
from the additional encryption.  Why would they deploy TLS?  There may
be those who produce similar media content who decide they WANT TLS. 
But it's their choice.

As to home printers, it's not that encryption is the problem- it's that
generating a valid cert in those environments is hard.

And as to Mike's statement:

> I doubt you would bother to install a valid certificate; you'd just
> use a self-signed cert or something, and because you've said you don't
> care about it, you'd ignore the warnings.

This is precisely the behavior you don't want to encourage, not to
mention it may not even work at all because of a lack of UI (this is one
generates a lot of broken software behavior).

A reasonable answer to all of this is for printers to stick with
HTTP/1.1.  Another reasonable approach would be to develop specific
solutions for this use case.  THAT is an area where some sort of "OE"
might in fact be appropriate.  But we don't have to do all of this at
once, and one design consideration I'd suggest we consider is that we
have appropriate hooks – if at all possible (and it may not be) – to
deal with some of this stuff later.

Eliot

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 24 Nov 2013 23:11:26 -0800

>> I doubt you would bother to install a valid certificate; you'd just use a self-signed cert or something, and because you've said you don't 
> This is precisely the behavior you don't want to encourage, not to mention it may not even work at all because of a lack of UI (this is one 

I could sum that as “UA does not have enough information, so the dialog is scary.” Over time, our browsers have evolved to show color codes that reflect some perceived security: green if https and the certificate could be verified, red if https and the certificate could not be verified, neutral if http. Consider now a web site that choses to use a self-signed certificate. If it advertises "https" URI, the browsers will flash red until the users do something really scary. If it advertises "http," then there will be no encryption. It seems that we need a third option, something like "http opportunistic," in which the browser knows that it does not need to put up a warning if the certificate is self-signed. 

-- Christian Huitema

---

From: Eliot Lear <[email-masked]>
Date: Mon, 25 Nov 2013 08:30:53 +0100

Hi,

On 11/24/13 8:22 AM, Mike Belshe wrote:

> But I don't want to hold up progress on HTTP/2.0 for everyone because
> of a very minority claim that legacy hardware performance is bad.

You're arguing a false premise.  That is- web sites that are looking at
aggregate costs in a competitive market compare against performance of
their peers.  This factors out legacy h/w.  I hesitate to go further
because the data here can lead to ambiguous interpretations, but it's a
sure bet that there will be classes of environments that have certain
performance characteristics that make HTTP/2 palatable, and others where
perhaps that tradeoff isn't worth it.  Wang et. al. at the University of
Washington  have recently done some excellent work on SPDY/3 that gives
us a taste for this.[1]

Eliot
[1]
https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final177.pdf

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 25 Nov 2013 13:22:39 +0000

Hiya,

> Are you saying that we should only be able to scan http, and not https?

I don't know to be honest. I'd say that'd be part of figuring
out the non-trivial answers as to how to handle proxies in
HTTP for which I think Mark has an open issue in the tracker.

> Or that we need to fix things so we can scan https without

What I've been saying (repeatedly, sorry:-) is that if a
solution for inbound malware scanning or similar is developed
for HTTP, then that needs to be done without breaking TLS, and
that standardising a generic MITM attack on TLS would mean
breaking TLS, which is used by many more protocols than just
HTTP.

S.

>>> use a

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 25 Nov 2013 13:28:27 +0000

Hiya,

> privacy for users of the Internet. Why not say so?

I'm fine if people talk about confidentiality enabling
better privacy, but not if people talk as if adding
confidentiality "adds privacy" or "gives privacy". To
give an example, even if every possible interaction
with a web site uses the best possible crypto, that web
site can (and today, often does) try to record as much
as possible about its users and some sites then sell
that information on to others.  In cases like that, the
user's privacy is arguably being damaged by the site,
no matter what's been done with the HTTP traffic.

However, adding confidentiality even then is still
worthwhile, as it does offer some protection against
network nodes that are in between the encryption and
decryption points.

So adding confidentiality does enable but does not
provide better privacy. And the problem with saying that
it does e.g. "increase the degree of effective privacy",
is that anyone who doesn't want more confidentiality (for
good or bad reasons) can correctly say that that
particular argument is bogus.

S

---

From: Zhong Yu <[email-masked]>
Date: Mon, 25 Nov 2013 10:33:21 -0600

> no matter what's been done with the HTTP traffic.

Adding to that point, the server end may proactively scan user data
and report illegal activities to authorities[1]. We can think of
several good reasons why big corporations want to grab that
responsibility.

It is misleading to say HTTPS is end-to-end encryption. It's more like
end-to-END encryption. The big END is not an equal partner of the
little end. The big END cares very much about the secrecy of the
conversation, but it probably does not coincide with the notion of
privacy that the little ends hold.

[1] https://news.ycombinator.com/item?id=6790018

---

From: Peter Lepeska <[email-masked]>
Date: Mon, 25 Nov 2013 16:09:20 -0500

"What I've been saying (repeatedly, sorry:-) is that if a
HTTP"

I agree with this point. I think we need to come up with a
protocol-supported way to solve the problems of trusted proxies without
modifying TLS.

Peter

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 25 Nov 2013 23:28:19 +0000

I think it could also be very useful if there were a way whereby a proxy 
could be queried for (or assert) policy in terms of:

* is https inspected (may even need to be able to signal this per 
stream)
* is tunnelling permitted etc
* what protocols and versions are supported

so that proper feedback can be given to the user to enable them to make 
informed choices.

In terms of the broader scope of whether "trusted proxies" deserve to 
exist or not. There has been some debate over this.  My view is that in 
the end the user has to trust something.  We don't currently have a 
system where no trust is required anywhere.  When you go to your bank 
site you trust that a bona fide CA properly issued the cert to your bank 
(after properly evaluating identity and authority for the cert holder to 
act for that domain).

Also we can rely on:

* malware authors to continue to use https.
* companies to still want to have a say in what their employees do on 
line or with company property (e.g. DLP)

I personally have more confidence trusting the edge inspection system 
run by my employer than a faceless corporation running a site or issuing 
certs.  I have an employment agreement with my employer, and employment 
laws protect me from a bunch of things, and I have redress in my 
jursidiction designed for issues between employers and employees (so not 
requiring mounting enormously expensive law-suits).  Not so if I have an 
issue with something done by a CA or website operator on the other side 
of the world.  If my company is running an off-the-shelf solution, there 
can be a level of confidence around that as well, in terms of the known 
capability of that software to breach my privacy or whatever as opposed 
to scan content for malware, or prevent me uploading sensitive company 
docs etc.

The current MITM systems are more clandestine than they should be purely 
because browsers don't have a way of knowing whether the root cert is 
real or not and so cannot warn users.  Proxies can't tell clients 
either.  There should be a deterministic way to signal these things to 
the client (e.g. mark a cert as being used for MITM or use proxy <-> 
client protocol).  Of course this relies on trust.  I don't think we can 
completely eliminate everywhere all need to trust, and attempting to do 
that compromises design and the opportunities we could have if we 
instead accepted the need to trust, and just made sure we knew what we 
were trusting and why.

Adrien

------ Original Message ------
From: "Peter Lepeska" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>
Cc: "Adrien de Croy" <[email-masked]>; "Tim Bray" 
<[email-masked]>; "[email-masked]" <[email-masked]>
Sent: 26/11/2013 10:09:20 a.m.
Subject: Re: I revised the pro/contra document
>> >>>>   Corporate IT guys long ago fixed this problem. Even for home 
>>use,
>> >>>> do you
>> >>>>  My home does not have the IT department of a Fortune 500 
>>company.
>> >>>> I'm sort
>> >>>>  websites already have valid certificates, then the growth of 
>>HTTPS
>> >>>> will not
>> >>>>  keywords, authors, people, links, etc) which can also be 
>>sensitive
>> >>>> itself.
>> >>>>  your neighbor know that you're researching <insert sensitive 
>>topic
>> >>>> here>?
>> >>>>   Ok, so when it comes to data in motion, how do we decide if TLS 
>>is
>> >>>>  useful?
>> >>
>> >>>>  if there were side effects to transmitting privately. For 
>>instance,
>> >>>> if my
>> >>>>  exchange private communications for lower cost. However, those 
>>of
>> >>>> us that
>> >>>>  have researched TLS in depth know that it can be deployed at 
>>near
>> >>>> zero cost
>> >>>>  It's not contentious, it's just false. Go to the pricing page 
>>for
>> >>>> Amazon
>> >>>>  has to bear. And you will get similar numbers if you host your 
>>site
>> >>>> on your
>> >>>>  own servers.
>> >>>>
>> >>>
>> >>>  prices are already TINY. I know 33% sounds like a lot, but this 
>>is
>> >>> not the
>> >>>  comparison, do an all-in price comparison. And you'll find that 
>>the
>> >>> cost
>> >>>  of TLS is less than a fraction of a percent difference in 
>>operating
>> >>> cost
>> >>>  for most businesses.
>> >>>

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Tue, 26 Nov 2013 10:48:30 +0100

Le Lun 25 novembre 2013 07:39, Eliot Lear a écrit :

Hi,

> solutions for this use case.

Really, haven't the past decade pretty much proved people did not want
one-of-a-kind protocols? http/1 success is that it was good enough for
everyone. http/2 should aim for the same sweet spot, not terrific for some
and useless for others

Regards,

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Tue, 26 Nov 2013 10:54:18 +0100

> breaking TLS, which is used by many more protocols than just

If properly specced it won't break tls anymore than sending mail to
foo.com through tls.smtp.gmail.com (that does malware scanning) breaks tls
(though being able to do it with message encryption again, like in mail,
would be great)

The whole problem here is that browsers and web sites got used to thinking
of https as end-to-end when the http protocol is explicitely hop-by-hop,
and when the hop-by-hop nature of http reasserts itself they see it as an
attack they try to "fix" instead of faulty expectations.

-- 
Nicolas Mailhot