Subject: SSL/TLS everywhere fail

From: Poul-Henning Kamp <[email-masked]>
Date: Wed, 02 Dec 2015 23:18:17 +0000

That happened faster than even I thought:

	http://telecom.kz/en/news/view/18729

-- 
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: Willy Tarreau <[email-masked]>
Date: Thu, 3 Dec 2015 00:42:22 +0100

> 	http://telecom.kz/en/news/view/18729

It was fast indeed. Nothing unexpected there, it has been predicated
on this list months/years ago as the natural outcome of the global
push for TLS everywhere, resulting in lack of security and privacy
where it was still granted before for the few sites where it was
relevant.

... waiting for this to happen here in Europe now. I'll pay you a
beer if you're hit before me :-)

Willy

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 3 Dec 2015 14:32:36 +0900

> 	http://telecom.kz/en/news/view/18729

It returns a 404 now, at least for me. Maybe they realized they didn't 
want the whole world to notice? Or it's just a local problem on my end?

Regards,   Martin.

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 3 Dec 2015 15:42:40 +1000

> want the whole world to notice? Or it's just a local problem on my end?
​Looks like they took it down. The essence was: "To ensure the safety of
our citizens, all TLS connections will be terminated at the Kazakhstan
​border, here is the government-provided root certificate you have to
install."

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

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 3 Dec 2015 07:31:28 +0100

On Thu, Dec 03, 2015 at 03:42:40PM +1000, Matthew Kerwin wrote:
> ???Looks like they took it down. The essence was: "To ensure the safety of
> ???border, here is the government-provided root certificate you have to
> install."

Too bad I closed my browser window just before reading this e-mail, I could
have copy-pasted it. Fortunately we have google cache, here's a copy of it
before it expires. We'll have other opportunities to read such messages in
the near future anyway.

Willy

---

  http://webcache.googleusercontent.com/search?q=cache:iNgneBgLnIUJ:telecom.kz/en/news/view/18729+&cd=2&hl=en&ct=clnk&gl=fr

  "
    Kazakhtelecom JSC notifies on introduction of National security certificate
    from 1 January 2016
    
    From 1 January 2016 pursuant to the Law of the Republic of Kazakhstan «On
    communication» Committee on Communication, Informatization and Information,
    Ministry for investments and development of the Republic of Kazakhstan
    introduces the national security certificate for Internet users.
    
    According to the Law telecom operators are obliged to perform traffic pass
    with using protocols, that support coding using security certificate, except
    traffic, coded by means of cryptographic information protection on the
    territory of the Republic of Kazakhstan.
    
    The national security certificate will secure protection of Kazakhstan users
    when using coded access protocols to foreign Internet resources.
    
    By words of Nurlan Meirmanov, Managing director on innovations of Kazakhtelecom
    JSC, Internet users shall install national security certificate, which will be
    available through Kazakhtelecom JSC internet resources. «User shall enter the
    site www.telecom.kz and install this certificate following step by step
    installation instructions"- underlined N.Meirmanov.
    
    Kazakhtelecom JSC pays special attention that installation of security
    certificate can be performed from each device of a subscriber, from which
    Internet access will be performed (mobile telephones and tabs on base of
    iOS/Android, PC and notebooks on base of Windows/MacOS).
    
    Detailed instructions for installation of security certificate will be placed
    in December 2015 on site www.telecom.kz.
    
    PR department
    Kazakhtelecom JSC
    
    30.11.2015
"

---

From: "Walter H." <[email-masked]>
Date: Thu, 3 Dec 2015 11:11:25 +0100

> 	http://telecom.kz/en/news/view/18729
in case you get nothing or 404 or other, try this:

http://web.archive.org/web/20151202203337/http://telecom.kz/en/news/view/18729

I think this is nothing real spectaculary,

just try this:

and look on the x509 SSL certificate you get from support12.cdnetworks.net
and there on the subject alternative names part,
there you will find: kimg.auone.jp
and then look at the x509 SSL certificate you get from kimg.auone.jp this
host;

very trustful isn't it?

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 4 Dec 2015 00:32:40 +1300

> beer if you're hit before me :-)

Can anyone elighten me; was that a phish? or an actual government action?

Amos

---

From: "Constantine A. Murenin" <[email-masked]>
Date: Thu, 03 Dec 2015 04:17:48 -0800

>      in December 2015 on site www.telecom.kz.

This is exactly what the "industry" has been asking all along.

You wanted all the web being encrypted?

	They're giving you encrypted!

Praising the deprecation of unencrypted HTTP?

	They've heard you, loud and clear!

Giving large warnings for self-signed certificates?

	OK, fine, we'll have our own CA, and'll import it for our users!

On a sidenote, isn't it a bit ironic how we've been building protocol 
and device interoperability and backwards compatibility for decades, 
only to now be told that a two-year-old phone is not supposed to be 
capable of accessing a public information resource website like ftc.gov, 
not because of extra life-saving features or a budget oversight, but 
purposefully because some zealots think that security buzz-words are 
more important than free information access by the means convenient to 
the public?

Here it is, the moment of zen:

% lynx -dump en.wikipedia.org

Looking up en.wikipedia.org
Making HTTP connection to en.wikipedia.org
Sending HTTP request.
HTTP request sent; waiting for response.
HTTP/1.1 301 TLS Redirect
Data transfer complete
HTTP/1.1 301 TLS Redirect
Using https://en.wikipedia.org/
Looking up en.wikipedia.org
Making HTTPS connection to en.wikipedia.org
SSL callback:certificate has expired, preverify_ok=0, ssl_okay=0
Retrying connection without TLS.
Looking up en.wikipedia.org
Making HTTPS connection to en.wikipedia.org
Alert!: Unable to make secure connection to remote host.

lynx: Can't access startfile http://en.wikipedia.org/
%

Where's backwards compatibility?

Where's a failsafe?

C.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 03 Dec 2015 13:15:26 +0000

--------

>Can anyone elighten me; was that a phish? or an actual government action?

It seems legit.  People on hacker-news seems to have found the
underlying government directives:

	https://news.ycombinator.com/item?id=10665344

---

From: Mike Belshe <[email-masked]>
Date: Thu, 3 Dec 2015 08:44:22 -0800

Absolutely to be expected, but nothing to do with http2.  This was already
happening long before http2 or spdy...

These types of event are GREAT for everyone - we're getting visibility into
just how invasive our governments want to be.  If we didn't push forward,
the world would be living in ignorant bliss.

Go go go http2 and mandatory SSL everywhere.  Next step - eliminate MITM.
We haven't done that well yet, but its coming.

Mike

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 3 Dec 2015 18:08:30 +0100

Hi Mike,

> We haven't done that well yet, but its coming.

Sorry Mike, but it's the opposite : SSL everywhere moves the value from clear
streams to encrypted streams, and creates the need for MITM in places where
they want to see what you're seeing even if it has little value for you.
Previously there was no need for breaking my PayPal connection because I
could read blog articles in clear text. Now when my government wants to see
what I'm reading, they also have the ability to break my PayPal connection.
And anyone participating in these activities as well.

The rule used to be pretty simple : if you don't want others to sniff you,
use SSL. Now since you don't offer that choice to users, it's "hey too bad
for you if someone sniffs you".

And I agree it's not HTTP/2 nor SPDY, it's the general trend towards SSL
everywhere that some companies are pushing hard, probably in part more to
try to protect the ad space they sell than to protect end users' privacy,
but that's my personal guess only and I could be wrong.

Cheers,
Willy

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 3 Dec 2015 17:20:39 +0000

> but that's my personal guess only and I could be wrong.

For me, the blame here is squarely on the despotic regime.

One can argue that folks acting from good motives achieving
more use of crypto (such as me, not a company:-) might lead
despots to react in that way, (but that is not what I think
you're saying), but even so I guess the regime in question
were likely already spying on as much as they could so what
has changed is that that is now being forced into the open.
(At which point I hope other mechanisms can help counter the
attack.)

S.

---

From: Mike Belshe <[email-masked]>
Date: Thu, 3 Dec 2015 09:25:46 -0800

> they want to see what you're seeing even if it has little value for you.

Off the shelf mitm has existed for years and long predates the SSL
everywhere movement.

> And anyone participating in these activities as well.

Maybe you don't read the news.  The NSA has been all over your paypal
connection for years....  Your employer has too.

> for you if someone sniffs you".

Willy, I'm surprised you think yesteryear's technology is supposed be
sufficient forever.  Security generally doesn't work that way.

People want privacy, encryption, security and safety.   They don't want it
sometimes - they want it all the time.  But you know this.  Instead of
lamenting how great it was in the past, lets move forward and build better
TLS.

Mike

---

From: Jacob Appelbaum <[email-masked]>
Date: Thu, 3 Dec 2015 17:29:04 +0000

> happening long before http2 or spdy...

Exactly so - huge surveillance and censorship events are an ongoing problem.

> the world would be living in ignorant bliss.

Rosa Luxemburg most famously captured this: "Those who do not move, do
not notice their chains."

I'm not sure that it is "great" in a sense that I'm familiar with...
it is a reality check that moves things along in a very honest
direction. Some technical people were aware and they were fine with
the status quo. Some as collaborators and some as feeling like this is
all awful and messy. Now many many more people will be aware, some
with power to change things and many without. It moves us from a world
of passive and hidden active attackers to a world where we'll see many
more active attacks.

Is it really bad news that we're now seeing this stuff? It has been
happening for *years* in some countries. Some Oakley groups have been
blocked wholesale in areas of the world.

> We haven't done that well yet, but its coming.

TLS, please. :-)

All the best,
Jacob

---

From: Cory Benfield <[email-masked]>
Date: Thu, 3 Dec 2015 17:35:51 +0000

> On 3 Dec 2015, at 17:29, Jacob Appelbaum <[email-masked]> wrote:
> 

I could not agree more with Jacob if I tried. Well said.

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 3 Dec 2015 19:01:07 +0100

> Off the shelf mitm has existed for years and long predates the SSL

I know and I don't care about MITM being performed on my *clear text*
browsing. But some companies decide that I should be forced to use
encryption even when I'm fine with MITM.

> connection for years....  Your employer has too.

NSA I'm not surprized. My employer I'm certain not. My ISP and/or government
maybe since in the ~500 CAs my browser recognizes, probably a few are rogue.

> sufficient forever.  Security generally doesn't work that way.

That's not what I'm saying, I'm talking about leaving the choice to end
users.

> sometimes - they want it all the time.

That's wrong. YOU want this and YOU decide that everybody wants this. I'm
NOT one of these idealist people because I know for sure that the ones who
have the power to enforce MITM have the power they need when they have to
come down on you. I prefer that they see my pointless browsing the easy
way instead of having them break my door and come with riffles while I'm
just checking google map to find the fastest way to go to my customers'
the next day.

> But you know this.  Instead of

Yes so that they need to break my door.

We've had this discussion together in the past, we both know we disagree
on this point and will probably never agree. Let's not re-heat it here.
At least I'm the one who does not try to impose his way of life on others,
I'd rather let everyone decide.

Willy

---

From: Roland Zink <[email-masked]>
Date: Thu, 3 Dec 2015 19:00:44 +0100

> Exactly so - huge surveillance and censorship events are an ongoing problem.
+1
> We haven't done that well yet, but its coming.
I'm a bit worried about all the closed boxes that I "own" but are really 
controlled by somebody else. Like a TV set reporting what channel I'm 
watching. The reporting is using TLS and is private, but how do I detect 
and prevent such things then? New chains everywhere.

Regards,
Roland

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 3 Dec 2015 19:05:54 +0100

> I could not agree more with Jacob if I tried. Well said.

Guys I think you didn't read well. What was reported is that a government
*officially* enforced the need to legally break TLS. If you're pushing
for more TLS, you're just pushing for more surveillance. That's a fact
and it has been proven by this news article. The push for TLS everywhere
has at least broken all Khazak's privacy.

I predict that in less than 10 years we'll all be using point-to-point
TLS because everyone will legally crack it along the way. What a great
internet it will be! It used to be limited for *certain* activities
only, making it uninteresting to crack most of the time.

Willy

---

From: Robert Collins <[email-masked]>
Date: Fri, 4 Dec 2015 07:32:39 +1300

On 4 December 2015 at 07:05, Willy Tarreau <[email-masked]> wrote:
> *officially* enforced the need to legally break TLS.

Just like the US government has done, and the 5 eyes network, and
others, have done stealthily for well over a decade.

> If you're pushing

The government mandated visible inspection of traffic that they can't
otherwise see *because* we've improved the baseline. It makes the
intrusion visible but it in now way changes the privacy that users in
Khazakhstan experience: their plaintext traffic is certainly already
compromised all the time.

> only, making it uninteresting to crack most of the time.

So when we make it infeasible to crack in a stealth fashion, and
attacks are visible to the populace, folk can decide if they are
willing to live in a panopticon, or if they want to strike down these
bad laws.

Complaining that the panopticon is becoming *visible* doesn't make sense to me.

As for whether the bulk of internet users want privacy: I haven't met
a single non-internet-technicalities-savvy person who didn't express
immense surprise at the idea that their normal browsing would be
visible to *anyone* other than the site they were browsing on.

I will happily admit that savvy users can choose to make a tradeoff,
but non-savvy users take time to become savvy, and we've 7 billion
people's needs to balance out. Is it less harmful to:

 - expose everything and then opt into security once you've learnt
enough about the architecture of the internet to understand whats
going on
 - protect everything and then opt into publicity once you've learn
enough about the arch...

The principle of least surprise suggests that protecting everything
and opting into publicity is better.

-Rob

-- 
Robert Collins <[email-masked]>
Distinguished Technologist
HP Converged Cloud

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 3 Dec 2015 11:39:41 -0700

On 12/03/2015 10:25 AM, Mike Belshe wrote:
> People want privacy, encryption, security and safety.

as well as control, freedom, pleasure, bread, and many other
incompatible and harmful-in-their-extremes things.

Let's leave political arguments, especially the insultingly simplistic
"people want [what I want]" ones, outside this technical mailing list.

Thank you,

Alex.

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 3 Dec 2015 20:06:49 +0100

On Fri, Dec 04, 2015 at 07:32:39AM +1300, Robert Collins wrote:
> otherwise see *because* we've improved the baseline.

That's exactly what we've been warning against for years. And not that
it's not "they cant' otherwise see" but "they're targetting the easiest
and cheapest way". In France if you want to see people's communications,
you first declare them terrorist and then you confiscate their PC, you
claim the data are encrypted, you ask for the key and if they refuse or
try to explain that there's no encryption, you put them in jail until
they change their mind (or they try to invent whatever they can if there
was really no encryption). And people applaud because one more terrorist
got arrested. I'm pretty sure it's the same in many other countries which
don't spend money cracking all SSL communications.

> It makes the

Did it ever come to your mind that it was possible that these people
didn't care a dime about their clear text traffic being seen by their
government, neighbors, coworkers, ISPs and whatever ? Most people
nowadays fear the *endpoint*. The big company on the other side knowing
everything about your life and suggesting when you should take your bus
before you even thought you could take a bus. You know, when you perform
a google search and you see a very small and discrete icon on the top right
showing your name and you say "ah shit, I just fed their base again", time
to log out.

> So when we make it infeasible to crack in a stealth fashion,

How do you as a user make the difference between the end point and the
MITM when technically they are the same devices implementing the same
protocols and the same keys ?

> visible to *anyone* other than the site they were browsing on.

That's exactly why some of us have said that education is more important
than false security. I've heard the media tell people for years that
without the small lock on their browser, everyone could sniff their
exchanges. But ISPs have been selling WiFi routers with default configs
and cleartext setups without telling anything. Then they have claimed
that WPA was secure. Etc. People trust what we tell them. Let's be
clear about the real risks and the real solutions.

> enough about the architecture of the internet to understand whats

How are the weather forecast or traffic jams considered "exposed"
when they're delivered for the widest possible public consumption ?

>  - protect everything and then opt into publicity once you've learn

Except that by protecting everything you immediately trigger the
"unprotect everything" weapon in the other camp.

It used to be the exact same with company proxies. Most companies
just want to have web-based anti-virus not to have to reinstall
their PCs all the time. They don't care about what you're doing on
the net because they made you sign a chart where you accept the
responsibilities for your actions. It used to work pretty well,
anti-virus software was able to analyse blogs and whatever. The
few tens to hundreds of sites requiring SSL were just whitelisted
after being validated by the admin as looking like "serious sites".

With TLS everywhere, these companies are forced to act as an MITM
to still enforce their anti-virus. Is it a problem for them ?
Absolutely not. Are the users at risk ? Absolutely. Because of this,
dumb admins which didn't have access to the encrypted traffic at all
now can see it in logs and sometimes even contents. They can snarf
it just for fun on a boring day. But doing this on certain commnications
is a really bad thing. And this was made possible by blind excess of
security.

Why do you think laws can pass to mandate decryption ? That's simple,
people don't fight because they don't care for their contents! But
you forced them to accept their few sensitive communications to be
decrypted in the process. They probably don't feel happy but they'll
trust their governments not to act badly because most of them consider
they have nothing to hide.

In France we had "hadopi" years ago, it mandated that ISPs sniff traffic
and report certain activities. Did people go down in the streets because
of this ? certainly not. If next year the government provides a national
certificate to decrypt everything and enforces it on ISPs, just like
last time, they will complain about the deployment cost but that will be
the only real reaction.

> and opting into publicity is better.

In theory I absolutely agree, except that you're not protecting against
random things but living beings which are smart and react to your actions.
That completely changes things. When you build protections against
earthquakes it's nice because the earth doesn't try to attack you. Doing
this against people who have many ways to get your data is just a way to
ensure their will use the next level of weapon to reach their goal.

Sometimes it's fun to feel stronger than the rest of the world, but it
can also come with great desillusions...

Willy

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 03 Dec 2015 20:37:06 +0000

------ Original Message ------
From: "Mike Belshe" <[email-masked]>

>
>Go go go http2 and mandatory SSL everywhere.  Next step - eliminate 
>MITM.  We haven't done that well yet, but its coming.
>
>
I think before you eliminate MiTM you better eliminate malware, and 
insecure sites that get hacked and become driveby attack sites.

And you better be prepared for everyone on the internet to forego 
caching.

I presume google will pay for infrastucture upgrade over the entire 
world so that people can get fast enough internet to not need caching?

Time to start working on a successor to TLS I guess for the sites we 
really want to be secure.

---

From: Matthew Kerwin <[email-masked]>
Date: Fri, 4 Dec 2015 06:58:40 +1000

> only, making it uninteresting to crack most of the time.

So... does Martin's encrypted content encoding fit into this predicted
future? And if so, in a good, bad, or neutral way?

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 03 Dec 2015 21:10:22 +0000

actually we may be saved in the end by human reluctance to spend money.

all those tens of millions of sites aren't going to want to buy an X.509 
certificate.

So they will stay with http/1.1 - all hail the failure of http/2

If Chrome decides to muscle people into encrypting their sites, e.g. by 
blocking or deterring unencrypted sites in the browser, maybe that will 
be Chrome's version of IE's "Internet Enhanced Security" feature which 
killed IE, and people will get sick of the nags and go to another 
browser.

------ Original Message ------
From: "Willy Tarreau" <[email-masked]>
To: "Robert Collins" <[email-masked]>
Cc: "HTTP Working Group" <[email-masked]>; "Cory Benfield" 
<[email-masked]>; "Jacob Appelbaum" <[email-masked]>; "Mike 
Belshe" <[email-masked]>; "Poul-Henning Kamp" <[email-masked]>; 
"Amos Jeffries" <[email-masked]>
Sent: 4/12/2015 8:06:49 a.m.
Subject: Re: SSL/TLS everywhere fail

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 03 Dec 2015 21:15:25 +0000

--------
In message <[email-masked]>
, Mike Belshe writes:

>These types of event are GREAT for everyone [...]

Speak for yourself Mike.

No, this not great for anybody.

You cannot fix political problems with technological hacks.

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 3 Dec 2015 22:20:18 +0100

> future? And if so, in a good, bad, or neutral way?

I don't know. It's always hard to know how technology can serve purposes
in the long term for good or for bad. It's the same reason some of us
warned against the naive TLS everywhere approach that was not going to
protect against sniffing but rather increasing sales of MiTM devices.
Some people didn't believe and they had very valid reasons for thinking
differently. Here I'm predicting a trend as a reaction for another trend.
What tools and methods will be used, I don't know. What I think however
is that some people will start to consider RFC1149 (or 6214 for IPv6) as
a serious alternative to the broken net they'll have to deal with.

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 03 Dec 2015 21:27:08 +0000

--------
In message <CACweHNALFPP9vRaWrpCJPXkD8Vf=[email-masked]>

>future? And if so, in a good, bad, or neutral way?

I think it fits in really well.

For one thing you can start communicating without a 3-way TLS handshake.

For another thing, you can use Pre Shared Keys of arbitrary strength,
and not have to pay the CA-mob protection money.

And most of all:  You can cache encrypted content, which will be incredibly
important for penetration of wireless technologies.

It will *also* allow governments to track who you talk to, but crucially
not reveal what is said.

That is what 99% of court-orders in civilized countries permit the
police to do, based on a showing of concrete suspicion of illegal
activities.

But is it perfect privacy ?

Of course not.

But ask normal people how they would expect police and courts to
redress wrongs, if everybody always have an inalienable right to
perfect privacy.

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 3 Dec 2015 15:26:37 -0700

On 12/03/2015 11:32 AM, Robert Collins wrote:

> I haven't met

I have met many technically-illiterate folks who assume their impersonal
communications are monitored by their government. If given the choice of
no internet or monitored internet, I bet many would pick the latter (and
would express immense surprise that they are being asked a question with
such an obvious [to them] answer!).

Our personal worldview, experience, and aspirations are not always
shared by the billions we are tempted to represent here (even if we dare
to characterize our current views as "enlightened" and worth mimicking
by those billions).

> Is it less harmful to:
>  - expose everything
>  - protect everything

Instead of deciding which extreme is less harmful, we should be focusing
on protocols and deployment recommendations that give people meaningful
choices without breaking infrastructure.

It is not this WG job to decide whether the Kazakh government (or the
example.com employer or a concerned parent) has the right to monitor
communication of their citizens (or employees or kids). It could be this
WG job to design protocols and deployment recommendations that make
monitoring easy to integrate, discover, and either consent to or reject.

Doing so would save a lot of energy for such useful things as educating
folks about surveillance trade-offs so that their consent (or lack of
thereof) becomes more informed.

Alex.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 4 Dec 2015 00:17:00 +0100

> such an obvious [to them] answer!).

Confirmed, I used to be one of those. For 12 years I've been using
Yahoo Mail to read my e-mails at customers' because it was the only
one allowing me to access my mail in clear, hence not being blocked by
corporate proxies. Oh and Yahoo's login box warned me about the insecure
aspect of this connection so I did it on purpose! I only had to tell
people not to send me sensitive information on this address since I
knew that potentially anyone could access it as well. And I've been
a happy user for all this time.

A few whiners used to make fun of me while complaining that they didn't
have e-mail access from the same places. Indeed it was the only one that
would pass since it was the only one that the anti-virus could analyze.
It's simply that different people have different priorities. Mine were
to have this access. Others probably had much more sensitive information
to exchange and couldn't afford a free unsecured webmail account.

+1

Willy

---

From: Piotr Galecki <[email-masked]>
Date: Thu, 3 Dec 2015 23:33:55 +0000

> "It could be this WG job to design protocols and deployment recommendations that 
> make monitoring easy to integrate, discover, and either consent to or reject."
+1

There are multiple use cases where a trusted intercepting proxy could come to play.
To name a few:
- monitoring of criminal activity by authorities
- preventing leakage of secure information by rogue employees
- filtering of malware and phishing sites
- optimizing user data for delivery over congested radio network

Piotr

-----Original Message-----
From: Willy Tarreau [mailto:[email-masked]] 
Sent: Thursday, December 03, 2015 6:17 PM
To: Alex Rousskov <[email-masked]>
Cc: HTTP Working Group <[email-masked]>; Robert Collins <[email-masked]>
Subject: Re: SSL/TLS everywhere fail

On Thu, Dec 03, 2015 at 03:26:37PM -0700, Alex Rousskov wrote:
> I have met many technically-illiterate folks who assume their 
> impersonal communications are monitored by their government. If given 
> the choice of no internet or monitored internet, I bet many would pick 
> the latter (and would express immense surprise that they are being 
> asked a question with such an obvious [to them] answer!).

Confirmed, I used to be one of those. For 12 years I've been using Yahoo Mail to read my e-mails at customers' because it was the only one allowing me to access my mail in clear, hence not being blocked by corporate proxies. Oh and Yahoo's login box warned me about the insecure aspect of this connection so I did it on purpose! I only had to tell people not to send me sensitive information on this address since I knew that potentially anyone could access it as well. And I've been a happy user for all this time.

A few whiners used to make fun of me while complaining that they didn't have e-mail access from the same places. Indeed it was the only one that would pass since it was the only one that the anti-virus could analyze.
It's simply that different people have different priorities. Mine were to have this access. Others probably had much more sensitive information to exchange and couldn't afford a free unsecured webmail account.

> communication of their citizens (or employees or kids). It could be 
> this WG job to design protocols and deployment recommendations that 
> make monitoring easy to integrate, discover, and either consent to or reject.
> 
> Doing so would save a lot of energy for such useful things as 
> educating folks about surveillance trade-offs so that their consent 
> (or lack of

+1

Willy

---

From: Jacob Appelbaum <[email-masked]>
Date: Fri, 4 Dec 2015 00:33:18 +0000

On 12/3/15, Poul-Henning Kamp <[email-masked]> wrote:
> --------
> In message
> <[email-masked]>
> , Mike Belshe writes:
>
> You cannot fix political problems with technological hacks

Nor can you fix it with political cowardice and security nihilism!

As has already been said in the thread: The technological changes
bring the political problems into a visible space. That gives us room
to change them in some societies and in other societies, we at least
know this small part of the overall score.

All the best,
Jacob

---

From: Ted Hardie <[email-masked]>
Date: Thu, 3 Dec 2015 16:38:27 -0800

On Thu, Dec 3, 2015 at 2:26 PM, Alex Rousskov <
[email-masked]> wrote:

>  It could be this
> ​ ​
> ​ ​

​The working group is constrained to work ​

​within the limits set out in general IETF policy.  In this case, that is
RFC 2804.

Look particularly at section 3.  As you will note from that, there are
certainly middleboxes which are within scope (configured HTTP proxies among
them).  But there are others which are not.  I know of no interception
proxy requiring a newly installed root CA which would fit within the
current policy, but I'm willing to be informed should there be one.  But
the common case is clearly outside the scope of the engineering efforts
appropriate to the IETF, according to our current policies.

regards,

Ted

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 3 Dec 2015 19:26:56 -0700

On 12/03/2015 05:38 PM, Ted Hardie wrote:

> On Thu, Dec 3, 2015 at 2:26 PM, Alex Rousskov wrote:
>     It could be this

> ​The working group is constrained to work
> ​within the limits set out in general IETF policy.  In this case, that
> is RFC 2804.

A good solution for the problems discussed on this email thread would be
"consent to be monitored". RFC 2804 does not apply to connections where
the parties know about monitoring and consent to being monitored
(Section 3 "wiretapping definition" conditions #1 and either #2 or #3
are not met, depending on the direction of the message). If there is
consent, there is no wiretapping per RFC 2804.

> certainly middleboxes which are within scope (configured HTTP proxies
> among them).  But there are others which are not.  I know of no
> interception proxy requiring a newly installed root CA which would fit
> within the current policy, but I'm willing to be informed should there
> be one.

The prevalence of interception proxies is our other engineering failure,
but if I have deliberately installed your root CA on my phone and
clicked "I agree to be monitored by Ted" button in my favorite browser,
then you are no longer wiretapping my Google requests per RFC 2804.

> But the common case is clearly outside the scope of the
> engineering efforts appropriate to the IETF, according to our current
> policies.

Today, there are actually two different kinds of common cases:

1. Good old stealth wiretapping (NSA and such).

2. Monitoring with consent (numerous employers, arguably many parents,
and, evidently, Kazakhstan(**)).

I am only talking about #2 category, which does not violate RFC 2804
letter or spirit AFAICT.

Thank you,

Alex.
(**) One could argue that installing a Kazakh NSA Root certificate is
not a strong form of informed consent. I do not necessarily disagree.
However, AFAICT, Kazakhstan authorities would have picked a more
user-friendly consent/integration method if IETF provided them with one:
They are _not_ hiding their monitoring, apparently, so it is reasonable
to speculate that they would actually prefer an easy, user-friendly
consent model to the current necessity of installing root CAs using
obscure configuration dialogs.

If not, please remove that particular example from #2 cases.

---

From: "Adrien de Croy" <[email-masked]>
Date: Fri, 04 Dec 2015 02:31:42 +0000

------ Original Message ------
From: "Jacob Appelbaum" <[email-masked]>

>know this small part of the overall score.

It's ironic you mention nihilism at the same time as the situation for 
those in Kazakhstan has been worsened, and whichever countries follow 
suit.

They are not equally as bad off as they were before.  Before they still 
had some security on https sites.  Now they have none anywhere, and they 
also get to live with the performance impact of the MitM as well.

I wonder if you would still have the same view if the US government 
adopted the same approach.

As for "fixing the political issue", that is not our job at all.

---

From: Mike Belshe <[email-masked]>
Date: Thu, 3 Dec 2015 19:47:03 -0800

On Thu, Dec 3, 2015 at 10:01 AM, Willy Tarreau <[email-masked]> wrote:

> That's wrong. YOU want this and YOU decide that everybody wants this.

One thing never changes:  the only people that don't want security are
those peddling archaic proxy products that don't work in the face of
encryption....

> I'm

OK - I'll stop.  You should too - you've replied with no fewer than 5 (yes
count them!) posts with the same tired old arguments...

The implementors (not me) have decided on a more secure transport - please
move on.  Its the same as how we decided on a reliable transport (tcp) and
not an unreliable one (udp).

Mike

---

From: "Adrien de Croy" <[email-masked]>
Date: Fri, 04 Dec 2015 04:13:19 +0000

------ Original Message ------

>those peddling archaic proxy products that don't work in the face of 

Obviously you never talk to people who use proxies.  I'd suggest you 
start talking to IT departments instead of just browser users.

We peddle these arguments because our customers make it plaint to us 
this is what they require

---

From: "Adrien de Croy" <[email-masked]>
Date: Fri, 04 Dec 2015 04:18:19 +0000

Actually this deserves another response

------ Original Message ------

>those peddling archaic proxy products that don't work in the face of 
This is wrong on all counts

We DO want security.  We just don't want the appearance of security 
which actually results in less security, which is what you are peddling 
and which we warned about all along.

Also proxies DO work in the face of encryption.  They have had to, and 
this is part of the arms race problem.

You're happy to make all these decisions for the billions of people, but 
I doubt you would be able to bear the cost of it for them. Or to make 
amends when it turns out that you were wrong.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 4 Dec 2015 15:31:28 +1100

> For me, the blame here is squarely on the despotic regime.

That might be unfair.  I happen to be related to a resident of that
fine country and that's not the general view.  Misguided, almost
certainly, and probably a great many other things, but I think that we
should be careful not to throw dem stones too hard.

Yes, the blame here likely lies with the government.  But labels like
that are unlikely to help.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 4 Dec 2015 15:34:26 +1100

> future? And if so, in a good, bad, or neutral way?

It's just a tool.  I encourage you to find new ways to apply it.
However, if you started to rely on it as a fallback for TLS... I think
that you would find yourself becoming quite sad.  Metadata is data.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 4 Dec 2015 06:24:36 +0100

> those peddling archaic proxy products that don't work in the face of

I don't think so since 1) I'm speaking as a user, and 2) the archaic
proxy product I'm working on works well in fact of encryption, and so
well that some users have even contributed the TLS MiTM functionnality
that their enterprise customers are asking for. Needless to say I wasn't
surprized since this natural outcome was predicted eventhough denied by
those who don't put their feet in enterprises.

> count them!) posts with the same tired old arguments...

I know and I don't want to continue either, I'm just amazed to see how
blind some people can be when facing facts : TLS was worked around by
law and disabled for a whole country, fine, let's push it even more so
that more people are denied the last bit of privacy they used to have,
since it's "great" to reuse one word I've read here...

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 04 Dec 2015 06:37:27 +0000

--------
In message <CAFggDF3aDuf6iZqr+n9yvKFfVVjvyntRL=[email-masked]>

>Nor can you fix it with political cowardice and security nihilism!

I don't think you can fairly accuse me of either ?

>bring the political problems into a visible space. 

Absolutely agree.

But SSL/TLS is just about the worst encryption you can bring to
that fight, because it is *so* trivial and routine to MiTM that you
can find the list-price for the necessary equipment on Google.

draft-thomson-http-encryption is a much better tool for civil
disobedience:  It can be used with a thousand diverse key management
schedules, including the only one we know to be intrinsicly secure
from MiTM (PSK), and there is *no* way to trojan all of it.

Deploy *that* with good key-management tools[1] and the politicians
will face the much more impalatable choice of "Block or Pass".

If they choose "pass" we won.

If they choose "block" we get the population on our side pretty quick.

Change the world with civil disobedience takes careful planning and
execution.  Rosa Parks didn't just happen to be tired.

Poul-Henning

[1] I hessitate to use the word GPG and "good" in the same context,
but there *is* a very large web of trust to leverage.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 04 Dec 2015 06:39:34 +0000

--------
In message <em716fa71d-9378-436e-b0c9-5a505cd8614b@bodybag>, "Adrien de Croy" w

>As for "fixing the political issue", that is not our job at all.

I would like to advocate the stance I have taken from the start of
my open source involvement:

	"We deliver tools, not policies"

Precisely the illadviced "SSL/TLS" everywhere policy being shoved
down peoples throat is a very good example of why.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 04 Dec 2015 06:44:08 +0000

--------
In message <[email-masked]

>- optimizing user data for delivery over congested radio network

- Parental controls

- Jailed inmates communication (as law permits)

- Recording the comms of financial traders to prevent insider trading

...

---

From: Werner Baumann <[email-masked]>
Date: Fri, 4 Dec 2015 11:06:40 +0100

Am Thu, 3 Dec 2015 17:29:04 +0000

> not notice their chains."

Didn't Rosa Luxemburg tell you that governments only act on behalf of
the real power and what that real power is?
So please move on against some big capitalist company that tries to
completely control Internet users and spy on them and that protects
this activities with TLS. You will feel the chains just as proxy
vendors already do.

Werner

---

From: Cory Benfield <[email-masked]>
Date: Fri, 4 Dec 2015 10:49:47 +0000

> On 4 Dec 2015, at 06:39, Poul-Henning Kamp <[email-masked]> wrote:
> 
> --------

Hang on a moment.

Poul-Henning, you and I agree on very little (which is fine, disagreement is healthy), but I think we agree that the TLS-everywhere policy pressured the Kazakh government to make this move. I personally believe they’d have done this eventually *anyway*, and we definitely disagree on whether TLS-everywhere is a good idea in the face of this move, but we can agree on that point.

However, I want to point out that *this working group* has, to my knowledge, never enacted any requirement that could be referred to as mandating, or even particularly encouraging, TLS-everywhere. RFC 7540, the most recent product from this group, quite expressly allows for plaintext HTTP/2: it even specifies how to negotiate and use it. That support exists in the wild, today: my implementations can do plaintext HTTP/2, several of the server implementations can do it, and I’ve used it on the open web myself.

As I understand it, your objection is not with *this working group*, it is with specific implementations (and possibly their representatives on this working group). Browsers and servers choose to restrict themselves to TLS-transports: the products of this WG do not mandate it. As a result, I believe a large chunk of the content in this thread is off-topic for this WG, and strictly on-topic for the mailing lists of implementations that implement only encrypted H2. I encourage those with concerns to take them to those implementations directly, rather than hoping that their concerns will filter through from representatives on this list.

Given that, as far as I can see what you want from this WG is not to stop specifying that TLS must be used everywhere, but to start specifying that implementations MUST support plaintext versions of all protocols they implement. In the absence of normative language, nothing is being shoved down anyone’s throats, at least not by this WG.

If you want to avoid TLS-everywhere being "shoved down" everyone’s throat, rather than posting emails that prove how wonderful you are at predicting changes in government policy, you should continue to use your influential voice when new drafts are discussed to ensure that they do not further contribute to the problems you are concerned about. Your voice, amongst others, helped keep a plaintext implementation of HTTP/2 in place in RFC 7540. You have the standards behind you: you can request that implementations relax their TLS-everywhere H2 policy.

Other useful actions, if you’re interested in the standards process, might be to consider requesting a revision of BCP 188 to cover your concerns, or proposing an additional BCP document that would help cover it.

What is *not* helping is about 50% of this thread, which consists of grandstanding and empty rhetoric. Matthew Kerwin very kindly attempted to shepherd this conversation onto the Encrypted Content-Coding document, and both you and others have provided useful feedback on that draft: that is valuable, thank you. Proposing new drafts or amendments to drafts is also helpful. Complaining about the behaviour of implementations in this forum is not helpful.

From where I’m sitting, this working group *does* deliver tools, not policies. As a result, I think your concern is best taken to the IESG or to individual implementations. This email thread is not helping the business of this WG.

---

From: "Constantine A. Murenin" <[email-masked]>
Date: Fri, 04 Dec 2015 04:43:46 -0800

> know this small part of the overall score.

Most people don't care about security in most circumstances, especially 
if they're just browsing the public internet or checking the weather.

What exactly do you gain by preventing access through forced encryption?

Why should I be denied access to public information?

(Heck, why is it even legal for US government to require mandatory 
encryption on all parts of federal websites like ftc.gov and fcc.gov?)

How is the mandatory TLS movement any different than the "dictatorship" 
regimes you claim to be fighting against?

Are people who are unable to access resources merely collateral damage?

C.

---

From: Jacob Appelbaum <[email-masked]>
Date: Fri, 4 Dec 2015 15:08:08 +0000

On 12/4/15, Poul-Henning Kamp <[email-masked]> wrote:
> --------
> In message
> <CAFggDF3aDuf6iZqr+n9yvKFfVVjvyntRL=[email-masked]>

No, I explicitly do not. Others are clearly guilty of both and some of
what I've read on the list was pretty... ugh.

We've discussed this in person and I think that very clearly we agree
that it is a political question. I think we also agree that all of the
choices of architecture are also political in nature. We probably
don't fully agree on solutions and I completely respect your process
for considering the problem space. Others simply disavow any
responsibility or pretend that their embrace of the status quo rids
them of any responsibility for consequences. I don't really see you in
that camp, frankly.

>>bring the political problems into a visible space.

Yes, I thought we did largely agree.

> can find the list-price for the necessary equipment on Google.

This is where we diverge, I suspect. None of that equipment is going
to work against PayPal or Google or even Tor Project's website when a
user uses a modern browser as those sites are TLS with cert pinning.

While many sites can be attacked - it requires a specific on-path
attacker with access to specific high cost cryptographic resources.
This is far less trivial than when the protocol is insecure by
default. It costs more to attack encrypted connections and it gives us
room to detect and in some cases to to stop attacks.

The design of a protocol that relies on an insecure transport is as
much of a political choice as the design of a protocol which relies on
a secure transport. The architecture of a system is also the
architecture of the politics of a system. I'm reminded of something I
read ages ago somewhere: "latent structure is master of obvious
structure."

> from MiTM (PSK), and there is *no* way to trojan all of it.

If it isn't deployed by default, I think it won't be a better tool in
practice. If it isn't easy to use and widely deployed, it will only be
a small part of the conflict.

> will face the much more impalatable choice of "Block or Pass".

We can't choose a single tactic - we need to push on every front. We
will have various tactical wins and losses, those results will ripple
out into larger strategic outcomes.

> If they choose "block" we get the population on our side pretty quick.

We may also disagree here - I think there is no winning, we just
change the cost of attacks for periods of time. A plantext protocol is
free to monitor, to attack and also it provides no effective detection
mechanism to those most impacted: our end users. This is completely
changed in Kazakhstan because of the methods the state has said that
they will use.

I'd bet that Kazakhstan will not actually carry out long term SSL/TLS
MITM attacks without incurring significant economic damage. The system
will likely have exceptions for special classes of people - especially
foreigners who travel on business. Even the "great" Chinese firewall
can be bypassed by buying a Deutsche Telekom SIM and using it while
roaming.

> execution.  Rosa Parks didn't just happen to be tired.

I'm in agreement. My civil disobedience is carefully planned and we're
having this discussion because there are many like me working in
similar directions. One of the key steps was to change the discussion
to understand that there is mass surveillance that is happening at
country scale. Another key step has been to build systems that provide
alternatives. Further steps are required, of course.

With all of that said - no one is forced to use TLS as other have
falsely claimed in the thread - they're all free to submit and hope
for mercy from the surveillance state. I'm not interested in that
path. We need strong defaults that enable people to make that choice.
Weak defaults do not give users a choice, they are tossed into to the
latent structure of the internet. If we make it secure by default,
*each person* can make the same choice to be *insecure* when they want
it. The majority of the world will be protected from the majority of
would-be-attackers when things are secure by default. It isn't perfect
but it changes things drastically.

> but there *is* a very large web of trust to leverage.

Ha! Poor GnuPG.

All the best,
Jacob

---

From: Jacob Appelbaum <[email-masked]>
Date: Fri, 4 Dec 2015 15:13:29 +0000

> the real power and what that real power is?

She was correct, I think.

> this activities with TLS. You will feel the chains just as proxy

Ironically some of the most successful capitalist companies are in
favorite of encrypting everything. They will help reduce the control
of the mass surveillance corporate vendors while also creating other
very serious privacy violations along the way.

All the best,
Jacob

---

From: Ted Hardie <[email-masked]>
Date: Fri, 4 Dec 2015 11:18:06 -0800

> then you are no longer wiretapping my Google requests per RFC 2804.
​It is also utterly unnecessary if I you are agreeing to be monitored.​  In
the case where you are agreeing to be monitored, you direct the traffic to
the inspection point.  This allows you to use cryptographic confirmation
that you are talking to the appropriate proxy, since it can provide you
such an assertion over that hop (which it cannot do the same if acting as
an interception proxy).  If you really have consent, deploying these root
CAs destroys the authentication property of the encrypted connection,
damaging the overall system, in a way that is simply not required.  That is
deeply sad for that class of cases, but mostly indicative that these are
mostly used where consent isn't present, because the organization involved
doesn't care to get it.

I am not sure who the "our" is in your "our other engineering failure" and
since the problem goes back a long way, there are likely participants in
this working group who have never known a web without this problem.  But
the baseline truth is that there have always been folks who have traded
their ease of configuration and lowered costs for their users privacy and
individual security.   Some of those run enterprise installations; some run
countries.  But the damage to the authentication properties of the system
is the same; it's just at different scales.

regards,

Ted

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 4 Dec 2015 14:15:46 -0700

On 12/04/2015 12:18 PM, Ted Hardie wrote:
> On Thu, Dec 3, 2015 at 6:26 PM, Alex Rousskov wrote:
> 

> ​It is also utterly unnecessary if I you are agreeing to be monitored.​ 

Unfortunately, MitM attacks on consenting participants are increasingly
necessary today. In practice, there is no support for the explicit proxy
to decode my browser connection to Google even if I am consenting to
that action. There is also no support for me to express that consent.
There is even no support for me to communicate with that proxy securely
while it analyses my traffic!

I am certain that a very significant portion (possibly more than 80%) of
monitoring cases that do not violate the spirit of RFC 2804 would not
utilize MitM attacks if they could monitor without them.

> In the case where you are agreeing to be monitored, you direct the
> traffic to the inspection point.

Yes, I can configure my browser to talk to a proxy. [ For now, let's
ignore the fact that it is difficult to do cost-efficiently in a diverse
environment with a thousand different user agents. ]

> This allows you to use cryptographic
> confirmation that you are talking to the appropriate proxy, since it can
> provide you such an assertion over that hop (which it cannot do the same
> if acting as an interception proxy).  

No, secure communication with forward proxies is currently not supported
by many popular browsers. They can tunnel HTTPS through a forward HTTP
proxy, but they cannot be configured to encrypt their connection to the
forward proxy using TLS.

However, let's ignore that huge problem as well. Let's assume I trust my
unsecure connection to the forward proxy.

Now, I enter "google.com" in my address bar and ... I get an error
because Google redirects me to a secure site and the forward proxy
cannot inspect my HTTPS communication with Google, blocking me despite
my consent to be inspected.

I have consented. I have set up an explicit proxy. The proxy plays by
the rules. And yet nothing works! At this point, my employer is forced
to attack my HTTPS traffic even though neither they nor me want to
resort to those dirty tricks.

> That is deeply sad for that class of cases, but
> mostly indicative that these are mostly used where consent isn't
> present, because the organization involved doesn't care to get it.

Unfortunately, getting consent changes nothing (as I illustrated above)
because we failed to provide the protocols and tools to support
consent-driven monitoring. While there are certainly cases of lazy and
careless organizations, the attacks would have been in the tiny minority
among organizations (and parents) if those tools existed (not because
they would stop being lazy and careless, but because it is very
difficult to make those attacks work _well_).

> I am not sure who the "our" is in your "our other engineering failure"

Folks making internet work, including IETF and this WG participants.

> and since the problem goes back a long way, there are likely
> participants in this working group who have never known a web without
> this problem.  But the baseline truth is that there have always been
> folks who have traded their ease of configuration and lowered costs for
> their users privacy and individual security.   

Very true. Another baseline truth is the lack of a standard,
widely-supported, easy-to-configure, low-cost method to setup explicit
proxies in diverse environments. It is us who failed to agree on and
provide such a method long time ago, and I doubt the situation will
improve for HTTP/3. Our collective failure skewed the scale for the
unfortunate trade you are describing.

Alex.

---

From: Martin Thomson <[email-masked]>
Date: Sat, 5 Dec 2015 09:45:48 +1100

On Dec 5, 2015 8:21 AM, "Alex Rousskov" <[email-masked]>
wrote:
> necessary today.

Isn't a big part of this debate over a disagreement about what is necessary?

> proxy, but they cannot be configured to encrypt their connection to the

Firefox definitely supports https proxies. I think that Chrome does too.

> resort to those dirty tricks.

But you are not the only party that has to consent. This is a two party
conversation, and it is very clear that the other party has not consented.
(Leave aside for the moment that this is still just a technical limitation,
you could write your own browser that would work in this situation. I could
even tell you how to disable pinning...)

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 04 Dec 2015 23:20:52 +0000

--------
In message <[email-masked]>
, Jacob Appelbaum writes:

>favorite of encrypting everything. 

... so that nobody else can see how they are violating the citizens privacy.

Yes, I don't see that as any kind of positive.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 05 Dec 2015 00:10:48 +0000

--------
In message <[email-masked]>, Cory Benfield w
rites:

>Poul-Henning, you and I agree on very little (which is fine, 
>disagreement is healthy), but I think we agree that the TLS-everywhere 
>policy pressured the Kazakh government to make this move. I personally 
>believe they'd have done this eventually *anyway*, and we 
>definitely disagree on whether TLS-everywhere is a good idea in the face 
>of this move, but we can agree on that point.

My point is that TLS anywhere made this *possible* for them.

MiTM of TLS is a COTS product.

If instead of rushing head-first into "TLS everywhere!!!!!" reactive
posture without a minimum of strategic planning, people had spent
a moment thinking forward, they would have realized that TLS
everywhere makes it *easier* to disable privacy in total, because
the entire infrastructure and *market* is already in place[1].

The correct response would have been to roll out more or less
*exactly* what the encryption draft contains, along with a wide
number of diverse key-management schedules.

That way the Kazakh government, no matter how much they desired it,
would not be able to do a MiTM on their entire country, because they
would not be able to get any tool from anywhere to implement it.

Their political choice would then be reduced to:

   A) Pass traffic, collecting only the "envelope",

or

   B) Block all traffic that cannot be inspected.

Even in Kazakstan B) would be politically suicide, so the result would
*at worst* be A).

A) Would have been a *much* better situation than what is now happening.

Now that they *have* implemented total MiTM, we fight the uphill
battle where they can (and probably will) block any other kind of
encrypted traffic than TLS, so rolling out our stronger weapon just
got impossble.

TLS-everywhere has played right into the hands of the "Crypto must
have back-doors" crowd.

>However, I want to point out that *this working group* has, to my 
>knowledge, never enacted any requirement that could be referred to as 
>mandating, or even particularly encouraging, TLS-everywhere.

So it wasn't committed to an RFC ?  Big deal.

I'm sorry, but the cheering was deafening, so don't come now and
claim that the people in this WG was neutral bystanders not taking
a position.

>As I understand it, your objection is not with *this working group*,

My objection is with naïve nerds who think that quick technical
hacks can solve heavy-duty political problems.

This WG has a solid majority from that camp, even if they never
wrote this one particular stupid decision into a RFC, but only
implemented it in their software.

>Given that, as far as I can see what you want from this WG is not to 
>stop specifying that TLS must be used everywhere, but to start 
>specifying that implementations MUST support plaintext versions of all 
>protocols they implement.

What I've been telling this group, is the exact same thing I have
been preaching everywhere else:

If you want to fight for your right to privacy, you shouldn't bring
a knife to a gunfight, you should get elected to your nearest
relevant legislature.

You may be able to enact RFCs, the people you are fighting can
enact laws, which police, courts and worst case military force
will back up.

While you work on the political side, you should certainly *also*
make sure that we can have "proportional response" in the technical
battle.

Doing that, we *might* have a chance of victory[2].

>If you want to avoid TLS-everywhere being "shoved down" everyone's
> throat, rather than posting emails that prove how wonderful you are at 
>predicting changes in government policy, you should continue to use your 
>influential voice when new drafts are discussed to ensure that they do 
>not further contribute to the problems you are concerned about.

You may not know this:  I make my living as a one man company writing
software.  I have no customers I can bill for IETF work and much
less can I afford to travel to IETF meetings, even if I wanted to
in the first place.

And yet I sit here at midnight, after a workday which started 16
hours and 800km away, answering your email.

And by the way:  The HTTP workshop was half of my summer-vacation this year.

So for the sake of my blood-pressure, I would *really* appreciate
if you will stop telling me how I should spend my time.

>What is *not* helping is about 50% of this thread, which consists of 
>grandstanding and empty rhetoric. 

If you consider this "empty rhetoric", then I probably have nothing
to contribute that you would consider germane.

I will point out though, that amongst my "empty rhetoric" was an
attempt to prevent HTTP/2 from just goldplating SPDY:

	http://phk.freebsd.dk/words/httpbis.html

I was told by several people that I didn't even need to bother
posting that as ID because it was a foregone conclusion that
HTTP/2 would be based on SPDY.

Despite that, I also worked with a group of other people to try to
come up with a protocol draft in the unreasonably short timeslot
which basically only allowed the SPDY people to make it.

And finally, I've been trying my damnest to to raise awareness
in any context I've had the chance, including one of the most
watched and talked about closing keynotes in FOSDEM history[4]:

	 https://www.youtube.com/watch?v=fwcl17Q0bpk

So yes, I'm full of "empty rhetoric" in an attempt to raise
the ground-swell we will need if we want to have a chance to
fight for a right to privacy.

If you think a well-written ID is a better way, be my guest.

Now get off my lawn...

Poul-Henning

[1] IHTSITYSBITYS

[2] I've never rated that chance particularly high, because I do not
    see young people being upset about the lack of privacy[3]

[3] If the 20-29 year old women do not go to bat for your cause, your
    chances of winning are non-existent base on the historical record.

[4] See also: https://twitter.com/csoghoian/status/672457784663781379

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 05 Dec 2015 00:20:45 +0000

--------
In message <CAFggDF2L1==[email-masked]>

>user uses a modern browser as those sites are TLS with cert pinning.

You're right.

PayPal, Google and the Tor Project will probably just stop working
in Kazakstan, and either they decide to follow the duly enacted
and valid laws of that country, or they will not be doing business
there.

For Kazakstan they *might* be able to shrug, although the track-record
indicates that the first two tend to follow local laws.

I have no idea what the Tor project will do, but fortunately the
human rights activists I know about has a fallback.

But have you followed the political discourse in UK recently ?

Will PayPal, Google and the Tor Project be able to shrug it off
when the UK government makes a similar move ?

>attacker with access to specific high cost cryptographic resources.

Dude, it's not high cost.  Kazakstan probably didn't even pay a
million dollars for their kit.

>We can't choose a single tactic [...]

That response is a little bit ironic, coming from one of the loudest
"TLS everywhere" advocates...

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 5 Dec 2015 11:22:16 +1100

> However, I want to point out that *this working group* has, to my knowledge, never enacted any requirement that could be referred to as mandating, or even particularly encouraging, TLS-everywhere.…

Correct.

> As I understand it, your objection is not with *this working group*, it is with specific implementations (and possibly their representatives on this working group). Browsers and servers choose to r…

Indeed. For those who might wonder, I'm not stopping this thread because it's interesting and germane to the use of HTTP, and because right now (i.e. over the last few days), we're in a bit of a lull, so it's not distracting from other work.

Cheers,

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

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 5 Dec 2015 00:31:14 +0000

(no hats)

On 05/12/15 00:22, Mark Nottingham wrote:
> Indeed. For those who might wonder, I'm not stopping this thread
> because it's interesting and germane to the use of HTTP, and because
> right now (i.e. over the last few days), we're in a bit of a lull, so
> it's not distracting from other work.

What if we said pretty please? :-)

S.

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 5 Dec 2015 11:39:29 +1100

PKH,

Responding as an individual --

> the entire infrastructure and *market* is already in place[1].

MiTM was a COTS product long before people started agitating for "TLS everywhere." It may have enlarged that market, but the technology was already there, and already a viable business for several vendors.

> number of diverse key-management schedules.

I'd encourage you to talk to some browser security teams to understand why that is not at all a viable replacement for TLS. The W3C's Web Application Security Working Group is a good place to start.

> implemented it in their software.

I think you're creating a straw-man here. No one has said that TLS everywhere is the only solution, or even a sufficient one. 

Indeed, much of the impetus for that effort is from other sources. Attacks like FireSheep and the Google Streetview drive-by illustrate how easy it is to gather data, and in modern life, much of our personal data is online. Add to that the increasing power of the Web platform (e.g., with geolocation, camera access, local data access, etc.), and HTTPS becomes necessary if only just for integrity and authentication. 

We wrote about this in the W3C TAG's "Securing the Web" finding: <http://www.w3.org/2001/tag/doc/web-https>

Cheers,

---

From: Ted Hardie <[email-masked]>
Date: Fri, 4 Dec 2015 16:40:43 -0800

> My point is that TLS anywhere made this *possible* for them.
​And were a majority of traffic in plaintext​ this would have been
impossible?  Harder?  I think maybe easier, instead.   Less expensive, to
boot.  Sure, passive analysis is easier yet, but MiTM of plaintext is
easier than MiTM of TLS on its face.

> number of diverse key-management schedules.
​There may also be more than one correct response.​  Doing more than one
thing may be required to get to a desired state, after all.

> encrypted traffic than TLS, so rolling out our stronger weapon just
​And your evidence for this is what, exactly? ​Combined with TLS, how does
your stronger weapon get weaker?

Ted

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 5 Dec 2015 11:41:22 +1100

> On 5 Dec 2015, at 2:08 am, Jacob Appelbaum <[email-masked]> wrote:
> 

Last I checked, browsers don't enforce pins when a MiTM CA is installed locally, and they don't intend to in the foreseeable future.

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 5 Dec 2015 11:46:19 +1100

> 	http://telecom.kz/en/news/view/18729

Interestingly, that now redirects to their home page. It's hard to say for sure, but I suspect they were surprised by the reaction and are re-thinking their plans. I suppose we'll (eventually) see.

Cheers,

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 4 Dec 2015 17:55:54 -0700

On 12/04/2015 03:45 PM, Martin Thomson wrote:
> 
> On Dec 5, 2015 8:21 AM, "Alex Rousskov" wrote:

> Isn't a big part of this debate over a disagreement about what is necessary?

Not in a technical sense. And we should not talk politics here.

> Firefox definitely supports https proxies. I think that Chrome does too.

For FireFox, this is a relatively recent and partial change, not yet
available via regular configuration options AFAICT. I have not checked
Chrome. It is nice that browsers are finally adding that support, of course!

> conversation, and it is very clear that the other party has not

First of all, RFC 2804 says that my consent (as the sender of requests
and a recipient of responses) is enough to exempt this use case from the
wiretapping definition. RFC 2804 does not require mutual consent.

Secondly, the other party has not been asked. AFAIK, there is currently
no protocol that can ask the origin server for monitoring consent so the
intent of the origin server is not very clear. Just because something is
transmitted over TLS does not automatically imply that the sender
objects to monitoring of that information by a *trusted* third party. It
only implies that the sender does not want untrusted third parties to
monitor the transmission.

Alex.

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 5 Dec 2015 02:09:16 +0100

> resort to those dirty tricks.

This is what ought to be covered by what we used to call the "GET https://"
a few years ago, ie : ask a trusted proxy to be the TLS endpoint. This would
get rid of a lot of legitimate MiTM devices and make them more suspicious
again. From what I remember from the conversations, the main difficulty to
address is how to let the user *clearly* know that his connection is going
to be seen by the proxy or is truly secure (CONNECT). The other one (less
important for the long term, might be a technical issue for the short term)
was that doing TLS inside a CONNECT tunnel over a TLS proxy connection was
not the easiest thing to do, probably in part because SSL libs APIs are even
harder to use between chained buffers than they are between a buffer and a
file descriptor. While this last point can justify some delay in deployment,
it should not be a showstopper at all. I find the first issue (user experience)
a real one that deserves some discussion though.

Willy

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 4 Dec 2015 18:42:03 -0700

> to be seen by the proxy or is truly secure (CONNECT). 

Yes, this is a challenging UI problem. It will take a talented and
_interested_ browser developer to solve it, so it may take many years
before such solutions cover enough traffic.

> The other one (less
> file descriptor.

Yes, I know. We have added https:// proxy support to Curl and had to
jump through a few hoops, including OpenSSL bugs:
https://github.com/bagder/curl/pull/305

> While this last point can justify some delay in deployment,

Since IETF does not do UI (AFAIK), the only thing we can do is to
publish an RFC that says an HTTP client configured to use a trusted
HTTPS proxy MAY, with user permission, send all https:// URIs to that
proxy instead of using CONNECTs. And then translate that into H2 speak.

And then wait 10-15 years for browsers to start supporting it :-).

Alex.

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 5 Dec 2015 03:01:26 +0100

> before such solutions cover enough traffic.

Some developers were moderately interested, because if we overcome the
UI issues it's obviously a saner situation for everyone, starting with
users. Clearly I'd like to be able to say "my webmail access are made
over TLS terminated at the proxy and my bank and paypal are done in a
tunnel through the proxy which whitelists them as considered safe".

> https://github.com/bagder/curl/pull/305

Ah interesting! Thanks for the pointer!

> And then wait 10-15 years for browsers to start supporting it :-).

I think that even if this WG is not working on UIs there are all the
relevant participants here who can propose or reject proposals for some
methods. We proposed some principles in the past but did not make progress
and there were other subjects to focus on. There's no doubt that the product
must be shipped as secure by default so that the user has to do something to
lower the security level. And even in this case it will be needed to support
exceptions to either mode.

The very first goal I was seeking with TLS proxies was to protect
authentication credentials. And immediately it appeared as the cleaner
way to at last let the user decide what content may be analysed and
what content may not be.

Willy

---

From: Zhong Yu <[email-masked]>
Date: Fri, 4 Dec 2015 20:10:43 -0600

> https://github.com/bagder/curl/pull/305

Ideally, client should be able to use multiple tunnels, plus one proxy

  client - Socks tunnel - CONNECT tunnel - more tunnels... - proxy - server

there are multiple levels of connections; each should be able to do TLS
so that it cannot be spied by the underlying connection.

I have a java http client that does just that, if anyone is interested.
  http://bayou.io/release/0.9/docs/http/Proxy_and_Tunnels.html

Zhong Yu
bayou.io

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 5 Dec 2015 02:32:12 +0000

Hiya,

On 05/12/15 00:41, Mark Nottingham wrote:
>>> that fight, because it is *so* trivial and routine to MiTM that
>>> you can find the list-price for the necessary equipment on
>>> Google.
>> 
>> This is where we diverge, I suspect. None of that equipment is
>> going to work against PayPal or Google or even Tor Project's
>> website when a user uses a modern browser as those sites are TLS
>> with cert pinning.
> 
> Last I checked, browsers don't enforce pins when a MiTM CA is
> installed locally, and they don't intend to in the foreseeable
> future.

So if the Kazakh situation were to pan out as feared, then
that would I think create a fine reason to re-open some of
the tricky questions around disregarding pins. RFC 7469, in
section 2.6 [1] says:

   It is acceptable to allow Pin
   Validation to be disabled for some Hosts according to local policy.
   For example, a UA may disable Pin Validation for Pinned Hosts whose
   validated certificate chain terminates at a user-defined trust
   anchor, rather than a trust anchor built-in to the UA (or underlying
   platform).

A situation where a govt forces or pressures end users at
home to install a root was not one that was considered when
that was thrashed out iirc. (If I'm remembering badly, then
pointers to the websec archive appreciated.) My reading of
the above (FWIW, me not being a browser implementer) would
be that coercing someone at home into installing a root
doesn't pass muster as something that's ok to ignore as it
is not a local policy for the person using the browser who
is the relevant policy authority.

Now, that'd be moot except in a situation where the world
was loudly told "here's the public key that folks <here>
had better install or else" in which case it could be feasible
for implementers to blacklist that key from being used
as a root. Technically, that's not very different from not
allowing someone to use the debian weak keys.

And indeed, if web sites were to know for sure that the
connections they see from such-and-such a TCP client are
in fact almost always MitM'd then those sites arguably ought
consider treating that connection differently, e.g. maybe
display a warning, or not allowing password reset perhaps,
if that could be done in a meaningful manner.

So interesting questions would arise in that "we're just
gonna force you member of the public to accept this MitM"
situation.

But, all of the above is still premature, (as is most of
this thread), as we don't yet really know what the actual
situation may end up being.

S.

[1] https://tools.ietf.org/html/rfc7469#section-2.6

> 
> Cheers,
> 
> -- Mark Nottingham   https://www.mnot.net/
> 
> 
> 
> 
> 
>

---

From: Jacob Appelbaum <[email-masked]>
Date: Sat, 5 Dec 2015 03:51:11 +0000

On 12/5/15, Poul-Henning Kamp <[email-masked]> wrote:
> --------
> In message
> <CAFggDF2L1==[email-masked]>

If I was a betting person, I'd bet they continue to work - except Tor
Project, I expect that to be blocked if it isn't already. Here is our
user graph for the entire year of 2015 for Kazakstan:
https://metrics.torproject.org/userstats-relay-country.html?graph=userstats-relay-country&start=2015-01-01&end=2015-12-05&country=kz&events=off

> human rights activists I know about has a fallback.

I suspect that they will use Tor bridges or another similar bypass
method. If they need help, we're always happy to help - please ask
them to reach out if we can help.

> when the UK government makes a similar move ?

People related to the Tor Project have been working to submit evidence
with regard to the latest series of bills on exactly this topic. I
guess other groups will do the same.

> million dollars for their kit.

I'm sorry if I was unclear: The high cost is a cert chain that works
on everyone without installing a root. The gear for MITM is of course
probably the cost of a few high quality tires on a tractor.

> "TLS everywhere" advocates...

Surely you're aware that I'm working on many different angles at the
same time - exactly in many of the areas that you suggest.

All the best,
Jacob

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 5 Dec 2015 08:17:19 +0100

A bit off-topic, but since it was brought here...

> https://metrics.torproject.org/userstats-relay-country.html?graph=userstats-relay-country&start=2015-01-01&end=2015-12-05&country=kz&events=off

I always find it a bit funny that the infrastructure that provides you
with a supposedly safe network respecting your privacy openly collects
data based on your source address and phones home to feed statistics
that are presented to the public. When you look at small places such
as Niue, you see between 0 and 1 user basically, so the deployment is
probably so small that everyone there knows exactly who's the person
being using Tor and can monitor his/her internet usage in real time :

  https://metrics.torproject.org/userstats-relay-country.html?graph=userstats-relay-country&start=2015-01-01&end=2015-12-05&country=nu&events=off

It may be a kid supposed to work on his lessons and whose parents are
monitoring from their workplace using this graph, knowing when he's
wasting his time on the net instead of working. This kid would have
remained unnoticed by *not* using Tor and maybe he doesn't understand
how his parents know he lies! That's always the problem when one
starts to get many users, it becomes hard to resist to the temptation
to collect data, it might be in human nature :-/

Willy

---

From: Cory Benfield <[email-masked]>
Date: Sat, 5 Dec 2015 08:18:59 +0000

> On 5 Dec 2015, at 00:10, Poul-Henning Kamp <[email-masked]> wrote:

It’s legitimately unclear to me that this is true. Going into a discussion of whether “just” metadata is better than metadata + data is not something I want to do on this list, but the idea that it’s clear-cut in favour of one side or another is not apparent to me.

> claim that the people in this WG was neutral bystanders not taking

Please don’t misrepresent what I said. I said “this WG”, not “members of this WG”. Individuals are not the aggregate. Many individuals in this WG did cheer for TLS-everywhere, sure, but the working group *as a whole* remained neutral on the topic. This was my original point.

> if you will stop telling me how I should spend my time.

That's is a fair point: I’m sorry, that was not my intention. Had I phrased that paragraph correctly, I would have said that you are more likely to be successful in your goals by continuing to be involved in IETF discussions to the best of your ability and time. Having been involved with this WG for a while now, I’ve seen you successfully use what little time you have to contribute and make your case.

I am sympathetic to your lack of time, because my response to your suggestion that I get elected to the House of Commons is a similar one: I don’t know where I’m expected to get the time. So, like you, I do the best I can: I write to my (useless) MP, I donate money to the Open Rights Group, and I try to vote for candidates that will take a more appropriate position on these issues.

> fight for a right to privacy.

I’m sorry, Poul-Henning, but my recollection is that I said that *this thread* was 50% empty rhetoric. The only comment I made about contributions outside this thread was a set of comments that were *positive* about your work in this working group. I did my level best to avoid attacking anyone in my email. Clearly I failed, for which I’m sorry.

> If you think a well-written ID is a better way, be my guest.

I do. I also think that I can’t write it, because I’m on the other side of the fence. This is why we need your voice.

---

From: Werner Baumann <[email-masked]>
Date: Sat, 5 Dec 2015 10:09:38 +0100

Am Sat, 5 Dec 2015 09:45:48 +1100
schrieb Martin Thomson <[email-masked]>:

> But you are not the only party that has to consent. This is a two
> party conversation, and it is very clear that the other party has not
> consented.

An important point that shows how asymmetric the Internet has become.
Does "the other party" (service  providers) ask for consent? They
delegate their services and content delivery to CDNs without even
asking the user for consent. They share information with whoever they
want, even in cases where it is illegal (at least when the user is an
European citizen).
But the user is not allowed to decide who is allowed to act on his
behalf?
There has been some subgroup in this WG that worked on a protocol for
trusted proxies. The demand that service providers can control whether
the user is allowed to use a proxy or not blew up the complexity of
such an protocol and there will surely be no result (if that subgroup
still exists).
No, I do not need consent from anyone to choose a proxy that I trust.
It is my decision to make.

Werner

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 05 Dec 2015 10:07:03 +0000

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

>MiTM was a COTS product long before people started agitating for "TLS 
>everywhere." It may have enlarged that market, but the technology was 
>already there, and already a viable business for several vendors.

And that is *exactly* why people should have thought "Hang on, If
TLS-everywhere is easly defeated by COTS products..."

>I'd encourage you to talk to some browser security teams to understand 
>why that is not at all a viable replacement for TLS. The W3C's Web 
>Application Security Working Group is a good place to start.

Nobody is talking about it being a "viable replacement for TLS",
and we don't need a "viable replacement for TLS", we need technical
response that can be ramped up, and up, and up, in response to the
other sides increasingly desparate attempts to break it.

No, it won't be plug in, and no, it may not make people the same
amount of money as usual.  But it *might* push our political
agenda forward as a means of "civil disobedience".

>I think you're creating a straw-man here. No one has said that TLS 
>everywhere is the only solution, or even a sufficient one. 

Ohhhh yes, a lot of people said that, also in this group.  I've
personally heard Jacob say it both in public and in priave over a
beer.  And yes, I shared my view.

>Interestingly, that now redirects to their home page. It's hard
>to say for sure, but I suspect they were surprised by the reaction
>and are re-thinking their plans. I suppose we'll (eventually) see.

Rumours from local sources is that it simply took their webserver
down.  No rumours about the government decision having changed.

---

From: Patrick McManus <[email-masked]>
Date: Sat, 5 Dec 2015 11:23:53 +0100

> Not in a technical sense. And we should not talk politics here.
The technical implications of policy (and vice versa) is certainly germane
to the making of standards. Things would be easier if that weren't true but
its not a good option to pretend otherwise. What we should avid here, imo,
is any talk not related to a standard we are working on even if it is of
general interest. This discussion seems in scope (if tedious :)).

> Chrome. It is nice that browsers are finally adding that support, of
Firefox "proxy over https" support was released in October 2014; Chrome
beat us to it. I've heard microsoft banter on the topic, but I'm not sure
if it is currently available. In both browsers you can do h1/h2/spdy over
that link - including mux'd connect tunnels within one h2/spdy session to
the proxy with proxies that support h2/spdy This has some really nice TCP
side-effects when done over poor links. Still waiting for several proxies
to pick up that feature. (that game works both ways :)..)

UI is done via PAC (which can be done without an external PAC file fwiw) in
both browsers. I think we will probably add a checkbox for it when we
update that configuration screen (For which I have a different reason to
schedule work anyhow, so this can piggyback).

But of course, this just authenticates the proxy and secures the transport
to it - it does not trust the proxy with https data split browser style. I
find it hard to imagine doing so would be in the best interest of our
users. Third parties that would like to be part of that conversation will
assert opportunity cost or just authority and disagree with my opinion.
cest la vie.

-P

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 05 Dec 2015 10:27:32 +0000

--------
In message <[email-masked]>

>them to reach out if we can help.

Obviously I am not going to say anything here that would compromise
anybody, but I can safely tell you that they are not in your dataset
for the graph you linked to, and that any contact to the Tor project
will be at least three arms length.

>guess other groups will do the same.

Sure.

And did you see what all the evidence did for the decision about
bombing Syria ?

>on everyone without installing a root.

If you are a government, the cost if getting everybody to install a
root-cert is probably cheaper than the kit.

In Denmark for instance, all the legislation is in place to require
people to accept a root-cert for our "NemID" (digital citizen/company
ID/ single signon), the cert can be downloaded as part of the logon
procedure and in a matter of days a very large fraction of all Danish
computers have the root-cert installed.

Other countries are similarly positioned.  Given their current
"cyber-war" threat-models, hey'd be stupid if not.

(NB: I'm not saying their threat-models are correct or even sane,
they're not, but given that threat-model, being able to roll out a
root-cert is the obvious thing to be able to do.)

>same time - exactly in many of the areas that you suggest.

I'd expect no less of you Jacob.

And I'll do anything I can do, including as much "empthy rhetoric"
as I can fit through my various megaphones.

In other related news:  The first news-item yesterday, following
the danish referendum (look it up) was "Denmark's NO means we cannot
participate in the new anti-terror flight-passenger database".  It
was made abundantly obvious that this was a TERRIBLE thing.

We have, so far, *totally* failed to get the population behind us
on this cause.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 05 Dec 2015 10:35:56 +0000

--------
In message <[email-masked]>, Cory Benfield w
rites:

>That's is a fair point: I'm sorry, that was not my intention. 
>Had I phrased that paragraph correctly, I would have said that you are 
>more likely to be successful in your goals by continuing to be involved 
>in IETF discussions to the best of your ability and time.

I have over the years managed to get various people to lend me their
megaphones on temporary and permanent basis, and in my view, that
is probably a better use of my time and energy, because if we don't
get the public at least moderately behind our cause, we're guaranteed
to lose it.

And yes, I'm still here on the mailing list, to the extent I have time.

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 5 Dec 2015 11:38:48 +0100

Hi Pat!

> to pick up that feature. (that game works both ways :)..)

Really cool! I know a number of people who will be quite interested, I'll
pass the message. I know some places where it will make a stop to the
awful cookie redirect dance. And this is a situation where there's no
fear for breaking non-browser devices since they already don't work :-)

> both browsers.

Yes I remember William explaining this for Chrome a while ago. That
seems reasonable for environments where https proxies matter.

> I think we will probably add a checkbox for it when we
> to it -

It's already critically important to "unbreak" many places playing the
redirect dance.

> it does not trust the proxy with https data split browser style. I

That's fine and it *must not* trust that proxy by default. User expects
the connection to be terminated by the browser (or the local malware but
let's not make things complicated) and we'll need to work on the "GET
https://" ideas to see how we can offer that control to the user to be
allowed to go out in controlled environments.

Willy

---

From: Jacob Appelbaum <[email-masked]>
Date: Sat, 5 Dec 2015 15:02:24 +0000

On 12/5/15, Willy Tarreau <[email-masked]> wrote:
> that are presented to the public.

By calling Tor "supposedly safe" and then stating various
unsupportable things about the statistics, I think this email is
likely a waste of effort. I hope I'm incorrect. None the less for
others on the list, I'll say the following:

The generalized statistics are documented here:

  http://freehaven.net/anonbib/#wecsr10measuring-tor

A great deal of questions and general information is here:

  https://metrics.torproject.org/about.html

The reason that this data is available openly is because we are trying
to ensure everyone has access to whatever data we might be able to
see. We want to make sure that we're not keeping anything secret
beyond say, bridge IP addresses which need to be kept private to
ensure that they're not blocked by censors. The relay operators are
the only ones that see user IP addresses, not us.

>  When you look at small places such
> wasting his time on the net instead of working.

I think you should read our design for privacy preserving statistics -
it is a rather off-list topic, so I won't bore the list. But claims of
"real time" monitoring are just completely wrong. If you'd like to
talk off list, I can point you at the same papers listed on the
website.

> This kid would have
> how his parents know he lies!

The graph does not confirm that it is him. Your assertion is baseless.
Also, I believe that the number one on that graph is actually
somewhere between 0-7 as per the way that our statistics are
performed.

> That's always the problem when one

The data is collected by nodes in the network and those who want to
help provide a very reasonable dataset that includes no PII other than
a general bucket with a fuzzy mapping of IP->country. To call that
collecting data on users is a bit of a strech when in fact, the relay
does all of the work, converts it and then only sends data when it
reaches a threshold that is considered safe. Relays can choose if they
want to be part of the metrics project.

All the best,
Jacob

---

From: Jacob Appelbaum <[email-masked]>
Date: Sat, 5 Dec 2015 15:10:35 +0000

> TLS-everywhere is easly defeated by COTS products..."

The model here is a bit strange. HTTP withou TLS is also easily
defeated. There is a cost here that is higher for the adversary and
that includes a political one: detection.

> other sides increasingly desparate attempts to break it.

I think we need a viable replacement for TLS where it is harder to
censor - layer violations ensure that an attacker can just TCP reset,
while off-path. TLS 1.3 with DTLS may be much harder to censor, for
example.

> agenda forward as a means of "civil disobedience".

I generally think that this is a good idea but it also misses a
critical pressure point: when we all use similar protocols, we can
help each other by blending in at the network level.

> beer.  And yes, I shared my view.

In defense of Poul: I have absolutely said that I think TLS helps make
the internet harder to govern from the desk of a censor. I also think
this is useful at times. We'll see how it plays out in the current
context of this particular country.

I think in many places - the cost of blocking all TLS is too high - so
selective blocking is required. That has been sufficient to change the
same. In some countries, we've seen the local censors give up or the
attacker math meant they focused on attacking Skype or something else
that was more pressing.

> down.  No rumours about the government decision having changed.

Now would be a good time to have diplomatic contacts reach out and to
confirm, as well as to discuss the future. Which would be a joke
topic, if it wasn't being discussed openly, which may have not
happened if it wasn't going to be a detectable event...

The change can't come from technology alone but for sure the ability
to ignore that it is happening is a good change.

All the best,
Jacob

---

From: Jacob Appelbaum <[email-masked]>
Date: Sat, 5 Dec 2015 15:21:10 +0000

On 12/5/15, Poul-Henning Kamp <[email-masked]> wrote:
> --------
> In message
> <[email-masked]>

Understood. None the less - the offer stands, if you have questions
for example, please do reach out.

> And did you see what all the evidence did for the decision about

I admit, I did not submit evidence for that topic. I also have a near
total lack of faith in say, the governments involved in those
activities. That doesn't help me with my latent cynicism. Still, I
think we have to look at each place where we can participate and then
we can make an impact by contributing informed information.

> root-cert is probably cheaper than the kit.

I do not believe that the root cert in question will be shipped by
browsers or devices without a user manually installing it.

> computers have the root-cert installed.

Yes, I can imagine that may happen - hopefully the cert would be
scoped for specific connections, domains or otherwise treated
differently.

> "cyber-war" threat-models, hey'd be stupid if not.

Yes, the next step is likely to escalate in this direction. We see it
in many places - still - the fact that things are detectable, fail
closed or require a user to consent will again, change the terrain of
struggle for everyone who cares about these issues.

> I'd expect no less of you Jacob.

Hooray. :-)

> as I can fit through my various megaphones.

Yes, I totally see that. I feel that it is clear that we're allies
even though we disagree about some of the issues.

> was made abundantly obvious that this was a TERRIBLE thing.

Interesting. The PNR system is a rich target for collection. Once the
EU has it running with long term data, it will only be as protected as
much as the most honest attacker decides to keep it protected.

> We have, so far, *totally* failed to get the population behind us

Many of the data collection issues at hand are as inaccessible as
critical facts in biology to entire populations. I'm not sure that
we'll find a way to deal with it until data is taken, leaked and/or
abused. It is very frustrating that systems at scale do not allow for
opt-out.

All the best,
Jacob

---

From: Jacob Appelbaum <[email-masked]>
Date: Sat, 5 Dec 2015 15:33:03 +0000

On 12/4/15, Poul-Henning Kamp <[email-masked]> wrote:
> --------
> In message
> <[email-masked]>

I don't think this is completely correct. We know it is happening and
often because other parties whine that they can't do it to those same
very users in secret!

> Yes, I don't see that as any kind of positive.

It isn't really a positive, I agree. Though it serves as an active
example which has benefits for creating a situation for change.

All the best,
Jacob

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 05 Dec 2015 16:07:29 +0000

--------
In message <CAFggDF1ckgL+mGN5NJKv9-Mj5b6MDkHdJC+3SVo=JJ2pKQd=[email-masked]>

>that includes a political one: detection.

Jacob, that's a false dictomy and you know it well.

I'm not advocating unencrypted HTTP, you can read what I
advocated here:  http://phk.freebsd.dk/words/httpbis.html

That is pretty much the same delineation as the draft we're
talking about now.

>confirm, [...]

Unfortunately I don't know anybody in Kazahkstan who can risk sticking
their head up.

---

From: Jacob Appelbaum <[email-masked]>
Date: Sat, 5 Dec 2015 22:59:23 +0000

On 12/5/15, Poul-Henning Kamp <[email-masked]> wrote:
> --------
> In message
> <CAFggDF1ckgL+mGN5NJKv9-Mj5b6MDkHdJC+3SVo=JJ2pKQd=[email-masked]>

Not exactly. We have started with unencrypted connections that lack
confidentiality, integrity and authenticity. Moving to TLS gives us
all three with a computational cost and within certain boundaries.
Some object to confidentiality, others to integrity and so on. A lack
of action on this has ensured that some protocols stay unencrypted -
an explicit goal of some of the bad actors who are present as agents
of influence in this (and other!) standards body.

> advocated here:  http://phk.freebsd.dk/words/httpbis.html

It seems that others are - by simply keeping the status quo. I see
that you explicitly discuss privacy and that you seem to advocate for
notification to the end user. I have to read the draft much more
carefully to really decide what I think. I think that I don't object
to the draft, generally. It sounds pretty reasonable.

> That is pretty much the same delineation as the draft we're

I think we may disagree about meta-data vs content and how we want
surveillance by unauthorized third parties to actually be conducted. I
think I'd like to see an explicit diagram for what a bad actor would
see when they watch your connection, illegally, for example. That is
lacking in your draft - what does it actually look like and what
actions can be performed by attackers?

It would be interesting to read an update of that draft with a
"surveillance considerations" section. It would especially be
interesting to compose it with Tor explicitly and see if together,
both protocols would give us something that we'd like to see but split
in reasonable ways.

> Unfortunately I don't know anybody in Kazahkstan who can risk sticking

Of course - I am suggesting that we ask people in Europe to hold
discussions with the Kazahkstan government over the issue. I am
planning to do so myself, next week, in the European parliament. Hope
to see you there or at PSC[0] afterwards. Or more on the mailing list,
much to do and all that...

All the best,
Jacob

[0] https://hyperelliptic.org/PSC/index.html

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 6 Dec 2015 11:30:24 +1100

> help each other by blending in at the network level.

Since we're talking about censorship evasion, folks might be interested in this:

<https://www.cachebrowser.info/>

"""
CacheBrowser is a system designed to help Internet users bypass Internet censorship.

The core idea of CacheBrowser is to grab censored content cached by Content Delivery Networks such as Akamai and CloudFlare directly from their CDN edge servers, therefore, foiling censors' DNS interference.
"""

I'm wondering (and that's just me, not speaking for my employer or anyone else) if there's something that can be done to make this a bit easier (and operate more smoothly); e.g. a format that lists DNSSEC assertions about delegations to a third party (like a CDN). 

Also, I've been working on a straw-man H2 extension in the background to tunnel IP over H2 (insert joke here). The idea being that if the connection doesn't have any discriminators vs. a normal HTTP one, any Web site could potentially be a VPN endpoint. It's true that traffic analysis is still possible, but it's a lot harder with multiplexing and padding. See:
 http://mnot.github.io/I-D/h2-vpn/
So far, I've had a few expressions of interest from non-browser implementers, but I think it needs to be built into browsers to avoid incidental discriminators. 

Cheers,

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 6 Dec 2015 19:47:17 +1300

On 6/12/2015 11:59 a.m., Jacob Appelbaum wrote:
> On 12/5/15, Poul-Henning Kamp wrote:
>> --------
>> Jacob Appelbaum writes:
>>

The tired old argument against "TLS-everywhere" is that TLS does *not*
offer all three of those.

* TLS does not offer confidentiality. TLS MiTM is commonplace now. It
has even reached the point where traffic metadata can be recorded and
correlated without decrypting the content of the stream.

* TLS does not offer integrity. TLS MiTM can corrupt the messages inside
encrypted streams just as easily as thay can for un-encrypted traffic.

When used with 2-way certificate verification TLS can offer
authenticity. But that is still a rare situation to actually see
implemented. Instead we see all sorts of half-measures (eg. HSTS, cert
pinning)

The benfits of TLS only occur when it is used properly in the situations
where it is the best tool. The "TLS everywhere" drive with its over
hyped arguments (and outright lies at times) is seriously undermining
those benefits by pushing it out into every possible connection no
matter how unsuitable TLS is for the use-case or broken the implementation.

The push back against "TLS everywhere" is attempting to ensure that
those privacy/confidentiality and security/integrity/authentication
goals can actually be *achieved*, instead of undermined by a rushed and
broken rollout that leaves the whole world in a worse place than
un-encrypted rollout did.

Lets slow down the hype train and do it *right*.

> of influence in this (and other!) standards body.

Please do not equate TLS with encryption. Encryption is much bigger than
TLS. A fact that the "TLS everywhere" fanatics are constantly shouting
out with their insistence that anyone doing encryption in non-TLS
settings is Bad Thing.

(I know you are not thinking of protocols like DNSSEC, VPN, or VPE as
unencrypted, but the implication is there.)

Amos

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 6 Dec 2015 09:00:54 +0100

> encrypted streams just as easily as thay can for un-encrypted traffic.

Warning Amos, TLS does offer this when it's used reasonably. The problem
is that when you want to enforce it everywhere, in order to break a few
of them, the other parties have to break all of them, which results in
TLS not offering any of these anymore. That's exactly why I'm opposed to
TLS everywhere. I want to keep these properties of TLS where I need them,
and for this I have to ensure my usage doesn't make it worth breaking it. 

To make an analogy, some people used to install some smoke detectors at
home and it used to save them. Some countries have made it mandatory to
install such devices at home, so it created a new interesting market for
unscrupulous vendors making cheap crap that beeps all the day without
any reason, so users end up disabling them and they can't find working
ones anymore since the market was replaced with 10 times cheaper devices.
The real problem here is the mass deployment which opened an opportunity
for doing bad things for end users security. Overall it certainly has
improved the situation but many people believe they're secured while
they are not.

Willy

---

From: Jacob Appelbaum <[email-masked]>
Date: Sun, 6 Dec 2015 08:27:46 +0000

> offer all three of those.

That argument is wrong when we consider how it is used in practice. As
an example, we upgrade a protocol from HTTP to HTTPS - we gain those
properties within certain bounds.

> correlated without decrypting the content of the stream.

Huh, please MITM my connection to my chosen Tor guard?

I'll concede you are correct when you can do so. You won't do so
unless you run a Tor guard and I choose you but that is of course, not
breaking the properties of TLS.

In many web browsers, you may be able to MITM them and if you choose
torproject.org with Chrome, even with a CA, you won't be able to MITM
the traffic in a way that breaks confidentiality unless you are my
chosen CA.

The exception is website fingerprinting - in that sense, I'll concede
that TLS has failures on large websites with know datasets. Especially
with SNI leakages and very specific websites that have very few pages
and an encrypted model is easy to build. Though that is probabilistic
rather than certainty.

> encrypted streams just as easily as thay can for un-encrypted traffic.

An active MITM must first break the authentication between a client
and a server. To claim that because this can be done, TLS doesn't
offer integrity is... not even worth a debate, I'm sorry.

> implemented. Instead we see all sorts of half-measures (eg. HSTS, cert

It isn't perfect and again, when we consider HTTP, we see that the
improvement is in every area with regard to... transport layer
security. Is it a perfect solution? No. Why not? Because it can be
destroyed by ... a TCP RST packet. There are dozens of other reasons
that TLS isn't perfect. But there are as many more reasons for
unencrypted protocols and those are suffering active and passive
attacks in an automatic fashion.

> matter how unsuitable TLS is for the use-case or broken the implementation.

I'm afraid I'm not familiar with the outright lies, could you cite
some and explain how they are lies? Can you for example cite them in a
way that makes them relevant to our discussion?

> un-encrypted rollout did.

Great, I look forward to your improvement to TLS. TLS is an
improvement for most protocols, especially HTTP. Perhaps it will be in
TLS 1.3? That protocol seems quite wide open and if you can come in
and break it, we can perhaps find a way to fix it before the standard
is finished.

> Lets slow down the hype train and do it *right*.

Could you define "right" in a world of ongoing, pervasive mass surveillance?

> out with their insistence that anyone doing encryption in non-TLS

{HTTP,IMAP,POP} to {HTTP,IMAP,POP} with TLS makes for a transition
from unencrypted to an encrypted connection. Other than with say, the
null cipher, of course.

The second part of your statement doesn't make sense to me and sounds
like a straw man. I'd love to see a citation to better understand your
view. In any case, I'm not saying whatever someone else may have said
about encryption, so could you clarify?

> unencrypted, but the implication is there.)

Huh? DNSSEC isn't encrypted and most VPNs are garbage encryption. The
few that aren't are personally or professionally run by Paul Wouters
and a handful of IETF people.  My deepest respect to them, by the way.
Basically everyone else is out to sea on a raft of backdoored crypto,
held together with SIGINT and denialism. Or they're using VPN
protocols which aren't specified by the IETF, sadly.

All the best,
Jacob

---

From: Jacob Appelbaum <[email-masked]>
Date: Sun, 6 Dec 2015 08:42:31 +0000

> and for this I have to ensure my usage doesn't make it worth breaking it.

I wish TLS made selective MITM impossible. We're working on it though!
Likely ETA is heat death of the universe, so no worries on that front
with your threat/caring/security model.

All the best,
Jacob

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 06 Dec 2015 10:58:23 +0000

--------
In message <CAFggDF21JqbKnnFcOr0=[email-masked]>
, Jacob Appelbaum writes:

>surveillance by unauthorized third parties to actually be conducted.

So since I'm waiting for a huge compile anyway...

I'm not a card-carrying historian, but here is my attempt to
contextualize government, privacy and secrecy:

Historically, people have been accutely aware of the difference
between keeping the metadata and the message secret.

Historically it has also been very hard to keep the metadata secret,
because metadata is essentially that communication is happening.

In classic art and literature, you will find thousands of references
to rulers and fathers receiving metadata:

   A courier was seen leave.

   Lights were being flashed.

   Letters were being sent.

   Telegrams were sent.

   Somebodys private secretary had left town.

   Somebody sent his son to the pope.

   The daughters maid has started gossiping with the young swains waiter.

   &c &c &c

More rare, but far from seldom, somebody take great pains to conceal
both message and metadata:  Carefully planned message paths through
unexeptional encounters, leaving in the dark of night, trusting
outsiders to carry messages etc. etc.

In all of this, protection and discovery of the metadata, that
communication is happening and with whom is being communicated, is
treated distinct and separate from the protection and discovery
of the actual message.

Indeed, it is more often than not the case that the actual message
is inferred with high precision, from the metadata.  After all,
there is only so many things a young man has to say to a young
woman, or a threatend ruler to the pope.

Integrity is a big issue and very often much greater effort and
creativity was expended on means to ensure it than on secrecy of
the actual message:  Sigils in laquer, leather, paper, and cloth.
Many interesting variations of torn money, swearing on bibles,
graves, honours etc. etc.

This leads me to the following observations for our current
times:

1)  If you *really* have something to hide, you should focus on
    protecting your metadata.

    Nobody needs to brute-force your session-keys to know what's
    going on if they know you had a two hour midnight web-session
    with 'aids-advice.example.com'
    
2)  In most cases the actual message does not need absolute or
    even any secrecy.  If I browse a major news-site, there is
    very little incremental information leakage in knowing which
    particular articles I read.

3)  Where secrecy is required, my web-commerce and banking as an
    example, we do so mostly to protect against simple crime.

    It is worth remembering that a simple paper envelope and modestly
    tamper-proof mail-boxes protected almost all the worlds
    commercial communication for the last 500 years.

4)  Integrity an authentication are much more important than secrecy,
    in both theory and praxis, but often treated as a side-effect
    of cryptography, rather than the goal of it.

5)  There are rare but legitimate reasons to demask communication,
    and in civilized societies we have carefully allowed for this
    and designed checks & balances to prevent abuse of this power.

If I project thos observation onto the HTTP-space, I get the following:

1)  If it *really* matters Tor is probably the _weakest_ facility
    you can and should use, and even the fact that you use HTTP
    should not leak through your protection.

    In other words:  The protection you use should be good enough
    that you could trust it with your plaintext, so this usecase
    does not impose any requirements on HTTP or any other "carried
    protocol"

2)  HTTP should offer Integrity separate from secrecy.  If nothing
    else to deter simple crime and for reasons of performance and
    caching.

3)  If the metadata, the fact that HTTP traffic is happening between
    two IP numbers, is not protected, attempting to protect the
    HTTP envelope and headers does not incrementally increase privacy
    enough for the downsides of doing it.

    The converse, moving the HTTP envelope and headers to the
    metadata column, (as the discusse draft could) can gain us a
    lot of valuable advantages in both efficiency and actual privacy.

    Most notably a lot of current MiTM proxies only want that
    metadata:  Who communciated with who ?  And a lot of them are
    in tricky legal positions if they get anywhere near the actual
    message content.

    Making it easier for law-regulated MiTM to only collect only the
    metadata they need, will therefore increase privacy, rather
    than decrease it.
    
4)  From a optimization and political point of view, we should only
    protect as well as necessary.

    Overprotecting is waste of resources.

    Politically over-protection causes over-breakage.

    If we over-protect, the easiest way to handle the legally
    mandated de-masking is to de-mask everything and sift the
    plaintext.

    If we protect the message only inside the metadata, only
    the targeted messages need to be de-masked.

And therefore TLS-everywhere falls down:

1)  It doesn't protect the most important metadata.

2)  About the only positive thing is that it does offer integrity
    (Provided you trust the CA-protection-racket)

3)  It pointlessly protects secondary metadata, which makes
    communication slower and more costly, without improving privacy.

    In the special case of legally regulated MiTM this even causes
    loss of privacy.

4)  It wastes computing resources[1] and it makes it cheaper for
    governments to break open all communication, and having broken
    it, it would obviously be a waste of resources to not collect it.

Feel free to use this text in any future ID's on the topic.

Poul-Henning

[1] We only have 10 years to get rid of fossil fuels now, every bit helps.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 06 Dec 2015 12:29:51 +0000

--------
In message <[email-masked]>, Willy Tarreau writes:

>Warning Amos, TLS does offer this when it's used reasonably.

There is no way to use it "reasonably" in practice.

The only tools most people have access to treats all
non-CA-protection-racket certificats like radioactive ebola virus.

>ones anymore since the market was replaced with 10 times cheaper devices.

That is a brilliant and on-point analogy!

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 06 Dec 2015 12:33:13 +0000

--------
In message <[email-masked]>

>properties within certain bounds.

For "within certain bounds" read:

	"Except any actor which has a trojan or captured CA - which
	means any non-incompetent state actor and many highly
	competent non-state actors."

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 6 Dec 2015 13:50:30 +0100

> There is no way to use it "reasonably" in practice.

But it's not TLS's fault but the whole model of trust. TLS works fine
in a trusted environment. By "trusted" I mean "you only rely on trusted
parties". When you have 500 unknown CAs in your browser that can emit
certs for whatever domain, you're probably not in a trusted environment.
When you have only CAs of parties you decide to trust, the whole chain
can be trusted.

You know well that like you I'm not fond of the resource impact it
causes on components like ours who need to extract routing information
from metadata that were encrypted without providing extra protection,
and that one of the reasons I think that content encryption is better
for some use cases. But when properly configured and with enough CPU
resources, it does work.

It's the whole ecosystem which is broken, not the protocol. The
protocol is not perfect for HTTP but it evolved to integrate better
(eg: SNI) and overall it remains the best solution we've come up
with for now.

> non-CA-protection-racket certificats like radioactive ebola virus.

I agree. If at least some of the large internet players started to
become their own CAs and to provide certs for free for everyone and
with various levels of validation, we could probably get rid of the
hundreds of CAs we're forced to trust and not have trouble getting
temporary certs for testing purposes or home use without the pain it
currently is nor the risks it represents to have your internal cert
stolen and reused to emit new certs in a targetted attack. Sites
using self-signed certs should be reported as almost-clear-text and
not cause any error nor warning.

willy

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 6 Dec 2015 13:54:25 +0100

> 	competent non-state actors."

Oh and BTW, how many of those who bought their smartphones from their
mobile operator verified that the operator has not pre-installed its
own CA in the phone to offer a "better experience" to their customers ?
By "better experience", you can understand "benefit from caching and
parental control without having to go through the difficult steps of
adding their CA yourself". And of course benefit from everything else
you didn't want to benefit from...

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 06 Dec 2015 12:57:25 +0000

--------
In message <[email-masked]>, Willy Tarreau writes:

>But it's not TLS's fault but the whole model of trust. 

No, it is the fault of the people who agitate for "TLS everywhere"
ignoring that the model of trust is utterly untrustworthy.

>When you have only CAs of parties you decide to trust, the whole chain

Correct.  And all current browsers make that as hard as possible
to do in practice.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 6 Dec 2015 13:35:19 +0000

Sorry to interrupt the flow of tls-is-bad but in amongst the
verbiage were two basic assumptions that I think highlight where
PHK and others with similar views diverge from what has repeatedly
been evaluated as the rough consensus of the IETF.

>     protecting your metadata.

The use of the singular "you" a number of times reflects a very
1980's view of the Internet - today a person who may or may not
have something to hide does not (in 99.99% of cases) have the
expertise to know what is involved in that and in many cases does
not even know what it is that may be worthwhile hiding. That person's
wishes and actions are mediated by many different sets of folks to
the point that text like the above and stories about "couriers" are
simply misleading fairy tales.

We (in the IETF) need to develop protocols that work well in this
kind of situation. BCP61 is one expression of that - strong security
needs to be available everywhere for us to do a good job. (Note that
I make no claim that we've done a super-good job at that, but we are
improving and getting more realistic I think as is shown by RFC7435.)

>     particular articles I read.

That's another divergence, BCP188 represents the IETF consensus to
work against PM, and it is abundantly clear that PM and many other
security and privacy threats benefit from use of cleartext HTTP
via tracking and via enabling the potential for injection of various
kinds. That the same is recognised for other protocols used in the
web is confirmed by RFC7626.

More and more I think we are learning that services such as
selective field confidentiality (which have always been very hard
to engineer) are in fact quite possibly damaging, both because
getting the field selection wrong may be inevitable and because the
added complexity could be beyond our ability to engineer at the
scale of the current Internet and web especially as that has
multiple parties involved, which HTTP does. Aiming for such an
outcome in the IETF context is not quite as bad as the magic
thinking of the likes of the current FBI director, but is close
to being as bad, as it is clearly unrealistic in the extreme.

Lastly, while the above quoted text I think does nicely highlight
this basic divergence of opinion, I think that divergence has been
entirely clear for at least a couple of years and that the many
many messages on this list in the last few days have clarified
precisely nothing but are simply repetitive and have basically no
information content. It'd be nice if that flow eased off or
even stopped.

Cheers,
S.

---

From: Jacob Appelbaum <[email-masked]>
Date: Sun, 6 Dec 2015 13:47:08 +0000

On 12/6/15, Poul-Henning Kamp <[email-masked]> wrote:
> --------
> In message
> <[email-masked]>

What is your estimate for the number of actors here with one or both capability?

My estimate is that malware is everywhere and certificates are less so.

In both cases, I think it is *higher* when we have unencrypted
connections - removing the requirement for a CA and it ensures that
malware can easily propagate as every connection to any service
creates a vector for infection.

All the best,
Jacob

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 06 Dec 2015 16:58:35 +0000

--------
In message <[email-masked]>, Stephen Farrell writes:

>not even know what it is that may be worthwhile hiding.
>[...]
>kind of situation.

In *some* of this kind of situations.

In the heavy-duty cases, such as Human Rights activists in a hostile
country, the fact *that* they communicate is the primary metadata
signal they want to attenuate.  IETF is no help there.

>BCP61 is one expression of that - strong security needs to be
>available everywhere for us to do a good job.

The Danvers Doctrine is politically naïve.

It doesn't recognize the authority of nation states and their
right to organize their internal affairs as they wish.

It doesn't acknowledge the existence of police forces and courts
as means to redress wrongs.

It doesn't even try to reference UNs Human Rights as a figleaf.

Consequently the Danvers Doctrine is an unconditional declaration
of war, against any kind of legal communication intercept, and
therefore it will never be able to collect the signature of a
single minister of justice, nor get endorsed by any legislature.

The Danvers Doctine leaves only two options for legislatures:

A) Do nothing, and see organized crime become impossible to investigate

B) Force all communication open with laws.

You don't need to follow the news very often to notice that no
politician near power in any state is arguing for option A.

The discussion is only about *how* 'B' will be implemented,
key-escrow, MiTM, backdoors and so on.

All of those options are stupid.

Stupid seen from politicians point of view, and (incredibly) stupid
seen from our point of view.

But those are the only options on the table, and since IETF and the
Danvers Doctrine offers no non-stupid options, stupid it will be.

>web is confirmed by RFC7626.

I don't know a single mentally competent person (in the legal sense)
who do not understand the distinction between things you do in
public space and things you do in private space.

BCP188, with the same unshakeable conviction as a 5th grade student
councils declaration to "end hunger in all the world", declares
that "There SHALL be no public space at all".

Until IETF stuffs ALL traffic through a Tor like construct,
there will be a public space that can be PM'ed.

The biggest problem in PM is reducing data, and NSA is grossly
incompetent if they expend a single bit of storage more if I read
washington post with HTTPS than with HTTP.

BCP188 probably made IETF-nerds feel good, but even if it manages
to encrypt 100% of the traffic on the net, it is not going to make
any positive difference in privacy for 95% of the traffic.

However it would certainly force legislatures to break the crypto open.

>to engineer) are in fact quite possibly damaging, [...]

Leaving your enemy with only the two options of "surrender" and
"start nuclear war" is in fact quite possibly damaging.

It is totally stupid when your strongest weapon, publishing text-files,
is up against enemies who can legislate, has taxing authority and
controls the police-force.

If the IETF wants to be taken seriously, it MUST acknowledge the
legitimate existence of UN, nation states, legislatures and court
orders demasking communication.

As long as IETF exists in the vacuum of its own political ignorance
it will be part of the problem rather than part of the solution.

Poul-Henning

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 06 Dec 2015 17:32:12 +0000

--------

>What is your estimate for the number of actors here with one or both capability?

My personal estimate is that the *cost price* of a bogus certificate
is $10K, to the people who have access to buy one from the source[1].

Price after traversing the blakck market is probably 10-100 times
higher, depending on the target.

>creates a vector for infection.

I wish competent people like you would stop talking about "encrypted"
vs. "unencrypted", because it is not the encryption itself, but
what it does for us that matters.

The biggest current protocol deficiency is that HTTP offers no means
to check integrity.

That could be done with a simple HTTP header and a thumbs-up icon
in the address-bar, and it wouldn't cost TLS startup overhead and
wouldn't impact the cachebility of the high volume traffic.

To the extent people paid attention to the thumb-up icon[2] it would
instantly prevent ad-injection, make a very large swath of simple
criminal activity impossible, and expose complex criminal activity
to a new range of legal risks (forging documents etc.)

Such calibrated measures, no matter their good cost/benefit, are
of course incompatible with the IETF's "all-out-war" attitude which
Stephen detailed in his email:  Integrity is routinely, as you just
did above, taken hostage for the "TLS everywhere" agenda.

Poul-Henning

[1] That is far too cheap.  IMO, the first time a CA is caught
    issuing a bogus certificate, it should be permanently black-balled
    from all root-cert lists.  The commercial consequences of lax
    security must be so draconian that lax security is NEVER an
    option for a CA.

[2] It would be obvious extension to use DNSSEC to indicate that
    all HTTP traffic should pass integrity.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 6 Dec 2015 17:35:45 +0000

> single minister of justice, nor get endorsed by any legislature.

Such risible rhetoric is frankly puzzling. I've no idea why
you think that kind of near-gibberish is useful to this wg.
(By gibberish I specifically mean your odd concept of having
some selection of the world's ministers for justice or
legislatures endorse an RFC.)

If, as seems to be the case, you have problems with the IETF
consensus on how to deal with security and privacy then you
should write an I-D and see if that garners consensus. I guess
you do know that this is not the right mailing list for that,
[email-masked] would be the place to start, not here.

S.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 06 Dec 2015 17:58:43 +0000

--------

>legislatures endorse an RFC.)

Do you really belive that writing "RFC" in the top right hand corner
of a document magically converts it from (radical!) political
manifesto to apolitical technical documentation ?

Which text-editor do you use that can do that ?

---

From: "Adrien de Croy" <[email-masked]>
Date: Sun, 06 Dec 2015 23:50:28 +0000

"Consensus"

It seems odd to me that "consensus" can be reached on things without 
even the knowledge of others.  I don't recall seeing anything about 
BCP188 on this list, so the "consensus" I would have to assume is a 
limited one, which hardly seems worth the claim.

And you wrote it yourself last year.

So that particular reference seems a bit self-serving.

And as far as I'm concerned, we don't really achieve true consensus on 
much.  Witness more recently the DNSOP .onion spec which requires 
building a time-machine to comply with.   The IETF is bigger than DNSOP 
or HTTPBis, so to claim "xx represents the consensus of the IETF 
community" is dubious at best.

And it is a u-turn on previous long-standing IETF "consensus" which is 
that we should not take a partisan stance.

Problem with taking a partisan stance is that when those with the actual 
power of states (e.g. legislature, judiciary, police etc) decide what we 
are doing is illegal, we create problems for our customers.  History is 
full of governments just doing what they want, look how Blackberry was 
blocked in India.  Do we really have the moral right to put users of 
products using our designed protocols at odds with the laws of their 
country "for their own good"?  Seems a bit irresponsible and callous to 
me.

The neutral stance I could live with, but we should not be taking a 
partisan stance, nor trying to state that the IETF thinks monitoring is 
"an attack" which is a highly loaded and pejorative term although I note 
that you attempt to address this in section 1, I don't think that 
message will make it across.

There seems to be a bit of a reality disconnect when denying any 
potential legitimacy to rights which are currently exercised by almost 
every state.  I wonder what the US state dept and many other government 
agencies around the world would think of BCP188 or what this WG is doing 
here.

------ Original Message ------
From: "Stephen Farrell" <[email-masked]>
To: "Poul-Henning Kamp" <[email-masked]>
Cc: "Jacob Appelbaum" <[email-masked]>; "Mark Nottingham" 
<[email-masked]>; "Cory Benfield" <[email-masked]>; "Adrien de Croy" 
<[email-masked]>; "Mike Belshe" <[email-masked]>; "Amos Jeffries" 
<[email-masked]>; "httpbis mailing list" <[email-masked]>
Sent: 7/12/2015 6:35:45 a.m.
Subject: Re: SSL/TLS everywhere fail

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 7 Dec 2015 00:07:55 +0000

> limited one, which hardly seems worth the claim.

Please look at the ~1000 messages in the [email-masked] archive on
the topic of that draft. Please consider the (video or whatever
form of reporting you prefer of the) technical plenary at IETF-88
with about 1000 people in the room who also expressed that same
consensus. (Albeit less precisely, which was the point of getting
the RFC done.)

httpbis is one of about 100+ IETF WGs. I fully understand that for
many folks it is entirely reasonable that this one WG is the limit of
their involvement in the IETF. But this isn't anywhere near the
entire IETF. Anyone who wants to is of course welcome to engage more
broadly but claims that there is a problem if something wasn't
discussed on one of the many many wg or non-wg lists aren't really
convincing.

> And you wrote it yourself last year.

I am a co-author yes. Or editor really.

Claims that BCP188 hasn't been exposed to significant and broadly
based scrutiny from many IETF participants are... wrong. ("Wrong"
wasn't the first word I typed:-)

S.

PS: I didn't check back but I think I recall mnot sending a link here
at one point asking folks to pay attention.

> country "for their own good"?  Seems a bit irresponsible and callous to me.
>

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 07 Dec 2015 00:15:04 +0000

------ Original Message ------
From: "Stephen Farrell" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>; "Poul-Henning Kamp" 
<[email-masked]>
Cc: "Jacob Appelbaum" <[email-masked]>; "Mark Nottingham" 
<[email-masked]>; "Cory Benfield" <[email-masked]>; "Mike Belshe" 
<[email-masked]>; "Amos Jeffries" <[email-masked]>; "httpbis 
mailing list" <[email-masked]>
Sent: 7/12/2015 1:07:55 p.m.
Subject: Re: SSL/TLS everywhere fail

>httpbis is one of about 100+ IETF WGs.
exactly my point.

I'm not saying there's an easy solution, but if you consider that one of 
the most monitored protocols is http, you'd think there would be more 
involvement of this WG for such a BCP, especially considering the extent 
to which we are affected by it.

Maybe there needs to be some more design thought put into how wider 
consensus of affected parties can be achieved, so that those who like 
you say aren't on a plethora of lists can still consider that the 
strength of the consensus is maintained, because AFAIC the whole purpose 
of the IETF is to attain consensus on things and represent the view of 
the community.

>I fully understand that for

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 7 Dec 2015 00:31:23 +0000

Hiya,

On 07/12/15 00:15, Adrien de Croy wrote:
> I'm not saying there's an easy solution, 

Yep.

> but if you consider that one of

"involvement of this WG" is a bit of a misnomer - people participate
(and not WGs) and if people choose just this one mailing list, that's
what they've chosen. (As I said before, doing so is entirely reasonable;
before I was on the IESG I would have ignored the crap out of many
IETF-wide discussions;-)

There were iirc quite a few people active in this wg who were
active in the discussion of that draft. I really don't think there
was any deficit in consideration of http in the development of
what ended up as BCP188.

> of the IETF is to attain consensus on things and represent the view of

Sure. If you have ideas on that then (again) [email-masked] is the right
place to start. Or perhaps [email-masked] or [email-masked]
if the topic is apps/RAI specific or [email-masked] if it's really about
security or privacy. There are already quite a few venues for such
things but they are all relatively imperfect and could do with more
sane input. (And as the IETF considers that one of our strengths is
cross-area review, most good suggestions that help with that are warmly
received.)

S.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 07 Dec 2015 01:09:21 +0000

--------

>consensus. (Albeit less precisely, which was the point of getting

The goals to be aimed for should certainly be a consensus decision,
and such "wide" processes are the norm:  General assemblies and
political party congresses etc.

BCP188 is typical for the outcome of such "wide" processes, and
similar lofty ambitions and language can be found in pretty much
any party or NGO platform document anywhere in the world.

The actual strategy for getting to those goals is usually laid down
by a much smaller group, taking into account the realities of the
battles to be fought and the relative strengths and weaknesses of
the opposition to be overcome.

IETF does not seem to have done that.

There are many valid and sound arguments why IETF should not or
even can not have a "central committee" or "leadership" of kind
which usually responsible for laying the strategy.

But lacking both leadership and strategy makes IETF, as organization,
totally unsuited to take on all the worlds governments in a fight
to win a basic human right of privacy.

...which is what BCP188 attempts to commit IETF to do.

Amnesty International and similar human rights organizations would
be much better vehicles than IETF can ever be.

Poul-Henning

---

From: Phil Hunt <[email-masked]>
Date: Sun, 6 Dec 2015 17:25:42 -0800

Let’s terminate this thread *please*.  It simply is not relevant to the HTTP WG.

Phil

> On Dec 6, 2015, at 5:09 PM, Poul-Henning Kamp <[email-masked]> wrote:
> 
> --------

---

From: Cory Benfield <[email-masked]>
Date: Mon, 7 Dec 2015 08:31:29 +0000

> On 6 Dec 2015, at 17:32, Poul-Henning Kamp <[email-masked]> wrote:
> 

Would you like to elaborate on how this would be done? Hashing the body content? Because an attacker can rewrite the header as well. Hashing the headers? Well, again, the attacker can rewrite those and recompute a hash on the entire thing. Signing the body? How does the client obtain the public key they use to verify the signature?

I ask these questions only because you used the word “simple”. The header itself (as in, the bytes on the wire) may be simple, but the technological underpinnings of this approach are *not* simple, at least as far as I can see. The best we have right now is a current I-D that aims to address exactly this, draft-thomson-http-content-signature[0], and that draft suffers from the absurd flaw that the signing public key is transmitted in unauthenticated cleartext right alongside the signature itself. The draft does save itself by allowing the key to be provisioned by other means, but omits to suggest what that would be.

As you have correctly identified in the past, Poul-Henning, establishing trust for crypto keys is tricky. You have objected to the CA system in what I would call “strong” language. Fine. Tell me how you want to do it for integrity checking of HTTP messages.

I am desperate for a good body-encryption draft, and I am desperate for a good integrity draft. You suggested in the above text that such a thing would be straightforward to build (*not* easy, straightforward). Good! Tell me how it should work, and I’ll even write the I-D for you, out of respect to your time constraints. I’d love to see this exist.

Cory

[0]: https://tools.ietf.org/html/draft-thomson-http-content-signature-00

---

From: Maxthon Chan <[email-masked]>
Date: Mon, 07 Dec 2015 18:15:44 +0800

A possible way:

1) The signature is done using the website’s normal SSL certificate (this can be transmitted in plain, just like when establishing TLS security)
2) The state of signature verification status as well as the signing certificate can be read in DOM so every website can check it in their own way later, even phone home when a fake certificate is encountered. The same can also apply for TLS trust status and certificate.

Now this, especially DOM access to actual certificate, can spark a cat-and-mouse game between MITM attacker and genuine site owner.

> On Dec 7, 2015, at 16:31, Cory Benfield <[email-masked]> wrote:
> 
>

---

From: Cory Benfield <[email-masked]>
Date: Mon, 7 Dec 2015 10:31:13 +0000

Well, PHK will object to (1) because he rejects the CA system as both politically and technically flawed. Further, (1) is, if implemented incautiously, open to the same kind of MITM attack that TLS is. You need a way to restrict certificates that can sign content for a specific origin. We've attempted to solve this (or at least improve the situation) for TLS: similar approaches would need to be taken here. 

For (2), I admit to not fully understanding what you're suggesting. However, my guess is that you're essentially saying that we'd punt by doing the validation in JavaScript, client-side, relying on the browser-side JS to validate the signature. That is of course open to the exact same attack as sending the cert in the HTTP: a MITM can replace the JS with one that would validate the content. 

The attack to worry about is: what if the attacker replaces the body *in its entirety*, headers and all? How do we protect against that? GPG does this by transmitting keys out of band using manual verification. TLS does this using the CA system, which has been further enhanced by HPKP and Certificate Transparency. How would we do this for the body content?

So far, I think (1) is workable, if subtle. However, I doubt PHK will go for it. 

Cory

> On 7 Dec 2015, at 10:15, Maxthon Chan <[email-masked]> wrote:
> 
> A possible way:
>

---

From: Maxthon Chan <[email-masked]>
Date: Mon, 07 Dec 2015 18:45:44 +0800

The point (1) is built on whatever TLS certificate system we settled down on so whatever improvement made there propagates here automatically.

The point (2) comes with the intention of sparking a cat-and-mouse game. The verification script can perform some kind of phone-home or whatnot, maybe loading part of the page pre-verification and some post-verification - the authors of legitimate websites together frustrate the potential MITM attackers by the sheer amount of ways of verification that can be done. Unless MITM attackers form alliances not unlike those antivirus companies they can have some difficulty in blocking all kinds of verifications, but such alliances can be easy to tell.

About whole-page replacements those are not even preventable theoretically. For example I don’t want anything within my network contact any server within a certain domain, I just set up my local firewall to redirect any address to that domain to blackhole.in.maxchan.info and serve a warning page instead.

> On Dec 7, 2015, at 18:31, Cory Benfield <[email-masked]> wrote:
>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 07 Dec 2015 10:53:55 +0000

--------
In message <[email-masked]>, Cory Benfield writes:

>I ask these questions only because you used the word 'simple'.
>The header itself (as in, the bytes on the wire) may be simple, but 
>the technological underpinnings of this approach are *not* simple, at 
>least as far as I can see. The best we have right now is a current I-D 
>that aims to address exactly this, 
>draft-thomson-http-content-signature[0], and that draft suffers from the 
>absurd flaw that the signing public key is transmitted in 
>unauthenticated cleartext right alongside the signature itself.

I am not sure I understand why you consider that an "absurd flaw"
and I have not been able to find any mail-discussion where such
a critique is raised.

Can you summarize the argument ?

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 07 Dec 2015 11:04:25 +0000

--------
In message <[email-masked]>, Cory Benfield writes:

>The attack to worry about is: what if the attacker replaces the body *in its
> entirety*, headers and all? How do we protect against that?

As in you get a bogus body and there is no signature ?

I think I'd lock that down with DNSSEC/DANE providing the information
that all HTTP under this domain must be signed with a particuar cert.

For real-time streaming traffic, it would be necessary with some
sort of "Transfer-Encoding: signed-chunks"

An escape-hatch, a signature which says "this object has other
integrity-checks" could be used for things like streaming video,
where integrity is built into the data already.

As for the CA thing:  My distrust is with the content of the default
root-cert lists shipped, not with the protocol mechanisms.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 07 Dec 2015 11:06:08 +0000

--------
In message <[email-masked]>, Maxthon Chan writes:

>The point (2) comes with the intention of sparking a cat-and-mouse game. 

I'd want it to be a mechanism which does not require a browser.

API traffic and IoS would be major markets for HTTP with Integrity.

---

From: Cory Benfield <[email-masked]>
Date: Mon, 7 Dec 2015 11:50:24 +0000

> On 7 Dec 2015, at 10:53, Poul-Henning Kamp <[email-masked]> wrote:
> 
> --------

To try to keep this discussion vaguely followable I’m actually going to compress your mails into one, Poul-Henning. Hope that’s not a problem. =)

The reason I characterise this as an "absurd flaw" is because it makes it trivial to mount an attack that replaces the content. For example, I run an API server that signs its content. We can do key distribution in one of three ways:

1. Ahead-of-time and out-of-band. For example, I could place the key on my API documentation website. This works, but I need to secure that website (TLS again!) to avoid manipulation of the key data.
2. TOFU: when you first login to my API I provide you, in-band, with the key I will subsequently use to sign all content.
3. I provide the signing key on all messages.

Both (2) and (3) make it possible for an attacker to listen to my API and rewrite those messages to provide new keys. This then allows the attacker to fool my user-agent into believing that the integrity of the message from the source is valid, where in fact the message has only been unaltered *since the attacker altered it*. In any communication, if the eavesdropper possesses a key that I will accept as valid for that communication, the data is essentially unprotected. This is, of course, how TLS MITM works.

In HTTPS we’ve started using HPKP to prevent this problem: that involves us using option (2). Option (2) is definitely better than Option (3), don’t get me wrong, but it’s still trivial for a pervasive attacker to simply replace all keys distributed by an authority. This is why Google distributes a HPKP preload list: to make it harder to attack the TOFU mechanism. We also require that HPKP headers only be emitted on TLS’d connections, which further increases the cost of pervasively editing the HPKP mechanism. It’s not perfect, but it’s a damn sight better than what the current draft requires.

As a result, I consider it extremely important that any implementation we have either be TOFU and have a normative requirement to cache that key indefinitely, or that it use some out-of-band key distribution mechanism. Otherwise, all an attacker needs to do is sit on the connection and replace both the body *and* the key: a relatively trivial thing to do.

> As in you get a bogus body and there is no signature ?

No, as in you get a bogus body and a valid signature for that bogus body, just signed by a different key than the one that was originally used to sign the body.

> I think I'd lock that down with DNSSEC/DANE providing the information that all HTTP under this domain must be signed with a particuar cert.

This is an answer to my question. What I wanted was a key distribution mechanism that provides integrity and associates keys with specific domains. DNSSEC/DANE is a perfectly valid answer. I don’t have a deep understanding of DANE myself, but it certainly strikes me as being appropriate, though I’d want to consult with others before I was convinced of that. If draft-thomson suggested DANE as a mechanism for key distribution, or indeed required DANE but allowed others, I would become much warmer towards the draft, and I’d certainly be open to seeing how implementing it goes.

For that matter, using DANE for the encryption draft as well seems sensible.

> As for the CA thing:  My distrust is with the content of the default root-cert lists shipped, not with the protocol mechanisms.

I admire your positivity towards X509, which I hate with a burning passion. That said, I take the point, and I believe that using DANE would address that concern for both of us.

To sum up: I think this draft is a good idea, but I think we should get ahead of this now and specify either at least one mandatory key distribution mechanism, or specify the properties such a key distribution mechanism must have. DNSSEC/DANE has been proposed, and I think it makes a good model for a useful system.

Now someone, please tell me why I’m wrong.

Cory

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 07 Dec 2015 12:13:11 +0000

--------

>> Can you summarize the argument ?

Thanks for the summary.

I find it a bit harsh to say that the proposed header/signature
format has an "absurd flaw" when the flaw complained about is 
really "key distribution is hard".

Yes, key-distribution can be hard, but that is a separate issue.

>As a result, I consider it extremely important that any implementation 
>we have either be TOFU and have a normative requirement to cache that 
>key indefinitely, or that it use some out-of-band key distribution 
>mechanism. Otherwise, all an attacker needs to do is sit on the 
>connection and replace both the body *and* the key: a relatively trivial 
>thing to do.

Again, this is the general key-distribution problem which have no
"ideal" and often not even "adequate" solutions.

But there are large swatches of the HTTP traffic where there are
perfectly good and workable key-distribution mechanisms, and holding
them up, waiting for a solution to an unsolveable problem makes no
sense.

To take one example:  API and IoS HTTP traffic almost always have
the ability to implement PSK, and key distribution doesn't get
any better than that.

There are also a lot of creative ways that key-distribution can
be boot-strapped in the browser-centric HTTP universe.

For instance I could open a HTTPS to a newspaper, and one of the
things I get back is the instruction:  "When you pick up our stuff
from the 3rd party CDN, the content must be signed with this key".

That could put integrity around an awfull lot of content which
simply doesn't need TLS because it is 100% public, with the
huge added benefit that the CDN's do need access to keys.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 7 Dec 2015 13:17:57 +0100

Hi,

> was any deficit in consideration of http in the development of

This is my recollection as well.

Eliot

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 7 Dec 2015 13:21:45 +0100

> Am 07.12.2015 um 13:13 schrieb Poul-Henning Kamp <[email-masked]>:
> 
> --------

You mean, do *not* need access to keys, right? 
As the origin would put the signature together with the content at the CDN, or?

//Stefan

---

From: Cory Benfield <[email-masked]>
Date: Mon, 7 Dec 2015 12:27:46 +0000

> On 7 Dec 2015, at 12:25, Adrien de Croy <[email-masked]> wrote:
> 
> 
> um
> 
> in TLS the Server cert message includes the server cert in ASN.1 format including the public key
> 
> So I don't see this being any different.  Or am I missing something?
> 
> Adrien
> 

The difference is that in TLS the certificate is *validated*: there is a process used for determining that the key in this certificate is acceptable to use for this data. The draft under discussion includes no such validation process.

Cory

---

From: Cory Benfield <[email-masked]>
Date: Mon, 7 Dec 2015 12:27:06 +0000

> On 7 Dec 2015, at 12:13, Poul-Henning Kamp <[email-masked]> wrote:
> 
> --------

I don’t think I’m quite complaining about “key distribution is hard”. If the draft had any text talking about the importance of key distribution, that would be a fair characterisation, but it contains nothing at all.

I agree that key distribution is hard, it’s terribly hard, and I need to say up from that I’m nowhere near smart enough to solve it. However, I think it is a dereliction of duty for this WG to not address the requirements of a key distribution system in anything we want to standardise.  We don’t need to solve it, and we don’t even need to be particularly strict, but we have a duty of care to ensure that systems we build for security actually *are* secure when implemented by people who don’t have the expertise of the people in this channel.

If we can’t solve the problem (and we certainly can’t *today*), then our mission should be to provide guidance and criteria by which key distribution mechanisms should be judged. Ideally we’d go further and recommend one for general use, because an RFC is useless unless you can use it to build something that has a reasonable shot at interoperating with other implementations.

I think the fairest criticism is actually that “Martin probably hadn’t got there yet”. I believe that Martin is aware of these problems, and I suspect my language was too aggressive, so I’m sorry for that Martin.

> them up, waiting for a solution to an unsolveable problem makes no

Sure, but please understand me: I don’t want “perfect”. I want *any guidance at all*. I want the draft to say *something* about the risks inherent in key distribution and the problems that a suitable key distribution mechanism must solve. Again, I don’t believe that any of the people in this WG would get this wrong, but we should write for people who are not us.

> the ability to implement PSK, and key distribution doesn't get

Yes, PSK is clearly totally acceptable. The draft should say so.

> from the 3rd party CDN, the content must be signed with this key”.

Good idea: in fact, I seem to recall that that was my item (1) in my list of key distribution techniques! However, that message needs to be standardised as being applicable to this draft. Perhaps some kind of registry of RFCs that talk about how keys can be distributed for signing purposes, which would allow both new mechanisms (like this one) and making existing mechanisms (the CA system) applicable for signing.

Basically what I’m saying is: I don’t want us to solve the key distribution problem. I want us to address the fact that it *is* a problem, so that implementers are not caught off-guard because they haven’t thought about it. I would like us to propose solutions to this problem. I think that generating standards that basically say “here’s a cool thing you can do if you have secure keys” without alluding to the problems of obtaining and controlling the use of those keys is insufficient.

Cory

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 07 Dec 2015 12:25:47 +0000

um

in TLS the Server cert message includes the server cert in ASN.1 format 
including the public key

Adrien

------ Original Message ------
From: "Poul-Henning Kamp" <[email-masked]>
To: "Cory Benfield" <[email-masked]>
Cc: "Jacob Appelbaum" <[email-masked]>; "Amos Jeffries" 
<[email-masked]>; "[email-masked]" <[email-masked]>
Sent: 7/12/2015 11:53:55 p.m.
Subject: Re: SSL/TLS everywhere fail

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 07 Dec 2015 12:34:37 +0000

--------
In message <[email-masked]>, Stefan Eissing writes:
>>=20
>> In message <[email-masked]>, Cory =
>Benfield writes:
>> [...]
>>=20
>You mean, do *not* need access to keys, right?=20

Correct, sorry for the typo.

>As the origin would put the signature together with the content at the 

Yes, basically the CDN gets the content with signature from origin
and doesn't even need to know what the signature means.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 07 Dec 2015 12:45:47 +0000

--------
In message <[email-masked]>, Cory Benfield writes:

>However, I think it is a dereliction of duty for this WG to not 
>address the requirements of a key distribution system in anything we 
>want to standardise.

I agree that if there were *no* key-distribtion available that
then it would be pointless to bless that draft.

But there *are* key-distributions available, most notably PSK.

>Yes, PSK is clearly totally acceptable. The draft should say so.

You know, I'd actually prefer the draft isn't bloated with
boilerplate text like that.  It should concentrate on the
task at hand and simply caution:

  "We remind the reader that Key-distribution is the only really
  hard cryptographic problem, do not take it lightly."

---

From: Cory Benfield <[email-masked]>
Date: Mon, 7 Dec 2015 13:05:41 +0000

> On 7 Dec 2015, at 12:45, Poul-Henning Kamp <[email-masked]> wrote:
> 

Here I disagree, I simply don’t think that goes far enough. Ambiguity in RFCs is bad. We need clarity about what is and is not acceptable. At the very least we need guidance on how to evaluate the options available.

Saying “key distribution is hard, you should look up how to do it” would, in my view, represent nothing less than a dereliction of duty on our part. In my mind it’s like having a specification for GPS and saying “Boy, gravity sure messes with clocks, that’s probably important here”.

I can sympathise with not wanting a content-signing draft to get too large. Fine. Let’s take draft-thomson-signing and draft-thomson-encryption, and have them both normatively reference a draft that talks about key distribution. We don’t have to detail it in those drafts, but in my view we absolutely have to talk about it somewhere.

(NB: There may be a suitable draft on key distribution that has come out of some other working group which we could reference that I’m not aware of. That would be fine. I don’t need it to be the product of HTTPbis, but I think it’s just unacceptable for us to say “use your best judgement”.)

Cory

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 07 Dec 2015 13:08:25 +0000

--------
In message <[email-masked]>, Cory Benfield writes:

>Here I disagree, I simply don't think that goes far enough. 
>Ambiguity in RFCs is bad.

That is not ambiguity, is pointing out that there are other
problem-domains, outside the subject of the present document, which
should be looked carefully at.

We also don't write treatises about transmission error detection
into every document which uses TCP.

---

From: Cory Benfield <[email-masked]>
Date: Mon, 7 Dec 2015 13:11:24 +0000

> On 7 Dec 2015, at 13:08, Poul-Henning Kamp <[email-masked]> wrote:
> 
> --------

Correct, we don’t, we refer those to the draft that talks about it. Which is what I want to do here.

Quoting myself:

> Let’s take draft-thomson-signing and draft-thomson-encryption, and have them both normatively reference a draft that talks about key distribution. We don’t have to detail it in those drafts, but in my view we absolutely have to talk about it somewhere.

and

>  I don’t need it to be the product of HTTPbis, but I think it’s just unacceptable for us to say “use your best judgement”.

Cory

---

From: Martin Thomson <[email-masked]>
Date: Tue, 8 Dec 2015 00:19:59 +1100

>> Let’s take draft-thomson-signing and draft-thomson-encryption, and have them both normatively reference a draft that talks about key distribution. We don’t have to detail it in those drafts, but i…

I apologize for missing this, I think that it's an important question
to address... (In my defence, the amount of digital ink spilled here
is beyond my current ability to track.)

I don't think that this is a sensible strategy.  There are a few uses
already for both drafts, both of which have very different key
management strategies.  Attempting to button this down in the way you
suggest would necessarily bless or condemn a whole range of
possibilities.

---

From: Cory Benfield <[email-masked]>
Date: Mon, 7 Dec 2015 13:24:03 +0000

> On 7 Dec 2015, at 13:19, Martin Thomson <[email-masked]> wrote:
> 

That’s a fair objection, Martin. Can I ask then, what some of these uses are, and whether they have commonalities? I’m still extremely concerned about having no guidance whatsoever on what to do here.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 7 Dec 2015 11:52:04 -0500 (EST)

[ Note I have not followed the discussion here, but was notified of
   my name having come up in this discussion, hence my reply here ]

> from unencrypted to an encrypted connection. Other than with say, the

I think what was meant was "TLS offers encryption, but encryption can be
offered by much more than only TLS".

> about encryption, so could you clarify?

I haven't seen that either. AFAIK, the "HTTPS Everywhere" people just want
all http to move to https and have https certificates be gratis. That is
a good goal and shows very clearly that non-EV certs are nothing more
than proving control of DNS(SEC) - and so people should just move to
use TLSA DNS records as the standard for DV certs, obsoleting industry
DV certs and "HTTPS Everywhere" along with it. I am looking forward to
the DNSSEC TLS extension that will make that move possible:

https://tools.ietf.org/html/draft-shore-tls-dnssec-chain-extension-02

> and a handful of IETF people.  My deepest respect to them, by the way.

Thanks for the vote of confidence, but... :)

First, let me clarify that while I am and have been involved with some
pretty big VPN and Opportunistic Encryption deployments, I don't "run"
any of them and have no credentials to any large production VPN (no need
to confiscate or steal my laptop). My personal focus is on everyone
running their own OE VPNs - governments ensured we cannot trust vendors
or service providers to do crypto as a service.

You can find a (somewhat dated) write up of that at:
https://nohats.ca/wordpress/blog/2013/09/12/history-and-implementation-status-of-opportunistic-encryption-for-ipsec/

There are many types of VPNs out there that are safe, but indeed a
lot of them that are not. The ones that are not are usually either
obsolete/old versions (like L2TP/IPsec or even plain L2TP or PPTP)
or other non-standarised solutions that haven't seen much research
(openvpn and a bunch of SSL VPNs come to mind). And of course a bunch of
basement crypto of people who only run their own designs, often fatally
flawed with no expert reviews and based on today's vanity encryption
algorithm. If people run VPNs based on a random github repository and
a tweet, nothing can save them.

But I do think most SSL/TLS VPNs that use up to date TLS as their
transport are very secure. OpenConnect is trying to do the right thing
and has smart software engineers behind it.

But TLS VPNs are impractical when you're dealing with UDPinTCP or
TCPinTCP connections. There is a good reason ESP/IPsec was not built on
top of TCP. Once you hit congestion or packetloss, the usability of
your TLS VPN goes down really fast. Sending UDP packets over TCP means
it's not really UDP anymore. And there is of course the TCP-RST
Denial Of Service attack.

The only good reason I can think of for TLS VPNs is to break through
networks that block IKE/IPsec VPNs by either administrative policy or
(hotel) incompetence. In fact, that is why the ipsecme working group
wanted to standarize IKE over TCP for a while. The current draft for that
is https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-00 but some
vendors (Checkpoint, Cisco, etc) already have their own implementation
of IKE over TCP to work around these broken networks.  I would recommend
these over TLS VPNs myself. Note while the draft technically is "IKE over
TCP" most implementations will ofcourse use port 443 and TLS, but only
to break out of a network - not for any kind of security or encryption.

> Then there are the ones that are safe
> from a technological point of view, but still vulnerable to government
> coercsion.

Yes, a real perception problem is that VPN service providers offer you
privacy. This is only true up to a point. It protects you from the
coffeeshop or your ISP, but not from the government that oversees this
VPN provider (or their domains, nameservers, cloudinstances, etc of
which usually at least one is under control of USG and thus secret NSLs)
Luckilly for those people, the vast majority of customers of these IPsec
based VPN services only use it to watch TV from a non-allowed geographic
region.

> protocols which aren't specified by the IETF, sadly.

Unfortunately, a lot of the "free software rebels" out there kneejerk
against standards organiations and end up designing their own without
the review required by a real community of experts. It also does not
help that the "cypherpunks" mailinglists are filled with the most
alienating kind of people that make it next to impossible to read the
good stuff in a sea of vile. Posting there requires a very thick skin.

IKE/IPsec had learned a lot from the mistakes of early SSL. And with
TLS 1.3 we see that TLS in turn seems to pick up on some of the IKE
properties. IKEv2 is finally seeing deployment, bringing some of the
much needed improvements to IKE/IPsec, similar to how TLS 1.3 brings
much needed improvements to TLS. Both are strong and have different
use cases. One protects a single network flow, the other protects all
communication between two hosts.  Since error reporting for thes two
use cases are very different, I think it's good that both protocols are
going to stick around for a while.

Paul

---

From: Piotr Galecki <[email-masked]>
Date: Mon, 7 Dec 2015 17:59:10 +0000

Ability to authenticate and encrypt HTTP traffic towards Proxy is great.
This should make it much harder to wiretap and monitor traffic on a web client to Proxy link by an attacker.

If Proxies received data as HTTPS they must use HTTPS on the upstream link (to an upstream proxy or origin server) to deter attacks on that link as well.

Mobile APN profile currently does not have 'use https' option.
If 3GPP would add that as an option that would improve user security.
I realize that this is out of scope for this working group.

Proxy itself, as long as it is legitimate and trusted by a web user, does not fall into wiretapping or Pervasive Monitoring definitions:
BCP 188 states that PM applies to "behavior that subverts the intent of communicating parties without the agreement of those parties.".
Since end user configured the proxy (as part of APN or WiFi profile) and therefore he did consent for the traffic to traverse through proxy.

Users however did not specify the extend of actions they authorized the proxy for.
Some Mobile Network Operators provide portals where users can specify what functionality
they want Operator Proxy to perform and from what functionality they want to opt out.
Some do not provide portals but if a user calls customer support and requests opt out they would enter the information into subscriber database.
There may be other ways how users authorize Proxy to perform parental controls, caching, web and video optimization, etc. 
Operator Proxies follow these user instructions.

Perhaps this WG could design an HTTP extension which would provide semantics on how this kind of authorization
could be done in HTTP itself rather than through an external portal?
When users attach a Proxy could send a list of functionality it provides and users could select which functionality they allow and which they want to opt out from?
Browsers could provide 'proxy indicator' with would allow users to modify the settings at a later time.
If the user requests Proxy to filter bad stuff (malware, phishing, viruses, pornography, violence) before it reaches its device, 
the protocol extension should give Proxy means to decode but not modify the content -- a decryption key would be shared with Proxy but not message integrity/signature key.
If the user requests Proxy to modify the content -- e.g. adapt video quality level based on current congestion level and bandwidth available in the radio network --
Proxy would get both decryption and integrity keys.
Does that sound like something completely off or perhaps a reasonable future HTTP/TLS extension?

Piotr

-----Original Message-----
From: Willy Tarreau [mailto:[email-masked]] 
Sent: Saturday, December 05, 2015 5:39 AM
To: Patrick McManus <[email-masked]>
Cc: Alex Rousskov <[email-masked]>; HTTP Working Group <[email-masked]>; Martin Thomson <[email-masked]>
Subject: Re: SSL/TLS everywhere fail

Hi Pat!

On Sat, Dec 05, 2015 at 11:23:53AM +0100, Patrick McManus wrote:
> Firefox "proxy over https" support was released in October 2014; 
> Chrome beat us to it. I've heard microsoft banter on the topic, but 
> I'm not sure if it is currently available. In both browsers you can do 
> h1/h2/spdy over that link - including mux'd connect tunnels within one 
> h2/spdy session to the proxy with proxies that support h2/spdy This 
> has some really nice TCP side-effects when done over poor links. Still 
> waiting for several proxies to pick up that feature. (that game works 
> both ways :)..)

Really cool! I know a number of people who will be quite interested, I'll pass the message. I know some places where it will make a stop to the awful cookie redirect dance. And this is a situation where there's no fear for breaking non-browser devices since they already don't work :-)

> UI is done via PAC (which can be done without an external PAC file 
> fwiw) in both browsers.

Yes I remember William explaining this for Chrome a while ago. That seems reasonable for environments where https proxies matter.

> I think we will probably add a checkbox for it when we update that 
> configuration screen (For which I have a different reason to schedule 
> work anyhow, so this can piggyback).
> 
> But of course, this just authenticates the proxy and secures the 
> transport to it -

It's already critically important to "unbreak" many places playing the redirect dance.

> users. Third parties that would like to be part of that conversation 
> will assert opportunity cost or just authority and disagree with my opinion.
> cest la vie.

That's fine and it *must not* trust that proxy by default. User expects the connection to be terminated by the browser (or the local malware but let's not make things complicated) and we'll need to work on the "GET https://" ideas to see how we can offer that control to the user to be allowed to go out in controlled environments.

Willy

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 8 Dec 2015 08:10:58 +1100

*with my chair hat on*

On 8 Dec 2015, at 3:52 am, Paul Wouters <[email-masked]> wrote:
> It also does not

Speaking of mailing lists that aren't serving their purpose well, I think it's time we wrap this thread up; the volume of traffic is (as a few have noted) become overwhelming, and we don't appear to be making progress on the topic overall, although the discussion has been interesting. 

If people have specific proposals for HTTP, I'd encourage them to write them down in a draft.

Cheers,