Subject: Fwd: IAB Statement on Internet Confidentiality

From: Mark Nottingham <[email-masked]>
Date: Fri, 14 Nov 2014 02:01:50 -1000

Everyone,

Please have a read through this carefully. Not only does it have potential impact upon future work — including any standards work around proxies — but it also may weigh on our current work (HTTP/2) when we take it to IETF Last Call.

Regards,

> Begin forwarded message:
> 
> From: IAB Chair <[email-masked]>
> Subject: IAB Statement on Internet Confidentiality
> Date: 13 November 2014 11:26:02 pm GMT-10
> To: IETF Announce <[email-masked]>
> Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-announce/ObCNmWcsFPNTIdMX5fmbuJoKFR8
> Cc: IAB <[email-masked]>, IETF <[email-masked]>
> Reply-To: [email-masked]
> 
> Please find this statement issued by the IAB today.
> 
> On behalf of the IAB,
>  Russ Housley
>  IAB Chair
> 
> = = = = = = = = = = = = =
> 
> IAB Statement on Internet Confidentiality
> 
> In 1996, the IAB and IESG recognized that the growth of the Internet
> depended on users having confidence that the network would protect
> their private information.  RFC 1984 documented this need.  Since that
> time, we have seen evidence that the capabilities and activities of
> attackers are greater and more pervasive than previously known.  The IAB
> now believes it is important for protocol designers, developers, and
> operators to make encryption the norm for Internet traffic.  Encryption
> should be authenticated where possible, but even protocols providing
> confidentiality without authentication are useful in the face of
> pervasive surveillance as described in RFC 7258.
> 
> Newly designed protocols should prefer encryption to cleartext operation.
> There may be exceptions to this default, but it is important to recognize
> that protocols do not operate in isolation.  Information leaked by one
> protocol can be made part of a more substantial body of information
> by cross-correlation of traffic observation.  There are protocols which
> may as a result require encryption on the Internet even when it would
> not be a requirement for that protocol operating in isolation.
> 
> We recommend that encryption be deployed throughout the protocol stack
> since there is not a single place within the stack where all kinds of
> communication can be protected.
> 
> The IAB urges protocol designers to design for confidential operation by
> default.  We strongly encourage developers to include encryption in their
> implementations, and to make them encrypted by default.  We similarly
> encourage network and service operators to deploy encryption where it is
> not yet deployed, and we urge firewall policy administrators to permit
> encrypted traffic.
> 
> We believe that each of these changes will help restore the trust users
> must have in the Internet.  We acknowledge that this will take time and
> trouble, though we believe recent successes in content delivery networks,
> messaging, and Internet application deployments demonstrate the
> feasibility of this migration.  We also acknowledge that many network
> operations activities today, from traffic management and intrusion
> detection to spam prevention and policy enforcement, assume access to
> cleartext payload.  For many of these activities there are no solutions
> yet, but the IAB will work with those affected to foster development of
> new approaches for these activities which allow us to move to an Internet
> where traffic is confidential by default.
> 

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

---

From: Matthew Kerwin <[email-masked]>
Date: Fri, 14 Nov 2014 22:27:04 +1000

This leaps out at me:

> There are protocols which may as a result
> require encryption on the Internet even
> when it would not be a requirement for that
> protocol operating in isolation.
>

I just want to confirm that the http/2 protocol we're developing is
intended for both the open internet and operation "in isolation."

This missive makes me wonder if we shouldn't start working on that
"deployment guidelines" document that's been mentioned from time to
time, to try and have something published at the same time as h2 that
says, "always use https/tls on the open web."

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

---

From: Jim Manico <[email-masked]>
Date: Fri, 14 Nov 2014 20:53:05 +0800

> ... to try and have something published at the same time as h2 that says, "always use https/tls on the open web."

+1 :) Good call. What about cert pinning and HSTS, can you include those in your announcement? 

--
Jim Manico
@Manicode

> On Nov 14, 2014, at 8:27 PM, Matthew Kerwin <[email-masked]> wrote:
> 
> to try and have something published at the same time as h2 that

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 15 Nov 2014 15:11:58 -1000

> On 14 Nov 2014, at 2:27 am, Matthew Kerwin <[email-masked]> wrote:
> 
> This leaps out at me:
> 
> intended for both the open internet and operation "in isolation.”

Speaking off the cuff — this is the IETF, we develop Internet protocols. While it’s true that by nature many Internet protocols are useful without being connected to the Internet, I don’t see that being a significant constraint of how we design or document them.

The applicable part of our charter is:

“””
The resulting specification(s) are expected to meet these goals for common existing deployments of HTTP; in particular, Web browsing (desktop and mobile), non-browsers ("HTTP APIs"), Web serving (at a variety of scales), and intermediation (by proxies, corporate firewalls, "reverse" proxies and Content Delivery Networks).
“””

This heavily implies internetworked systems (including clients and servers “behind the firewall”).

At any rate — because of where we’re at in the HTTP/2 discussion, we’re not going to reopen the debate based upon what we think the IESG *might* do; rather, we’ll wait until they actually do it (i.e., DISCUSS and return the document to us), if they actually do it.

> says, "always use https/tls on the open web.”

Yes, we might go there.

---

From: Mike Belshe <[email-masked]>
Date: Sun, 16 Nov 2014 09:00:42 -0800

Hey Mark -

This is fantastic.  Thanks for all you've done to make this happen.  Its
about time!

Great!

Mike

On Fri, Nov 14, 2014 at 4:01 AM, Mark Nottingham <[email-masked]> wrote:

> Everyone,
>
> Please have a read through this carefully. Not only does it have potential
> impact upon future work — including any standards work around proxies — but
> it also may weigh on our current work (HTTP/2) when we take it to IETF Last
> Call.
>
> Regards,
>
>
> > Begin forwarded message:
> >
> > Archived-At:
> http://mailarchive.ietf.org/arch/msg/ietf-announce/ObCNmWcsFPNTIdMX5fmbuJoKFR8

---

From: Roland Zink <[email-masked]>
Date: Mon, 17 Nov 2014 13:46:39 +0100

On a first glance HTTP2 doesn't look to bad regarding this. See some 
comments included.

Regards,
Roland

>> Please find this statement issued by the IAB today.
HTTP seem to give this to the content provider, but ALT-SVC and OPP-SEC 
seem to address this.
>> that protocols do not operate in isolation.  Information leaked by one
HTTP leaks information. Especially the content provider can add 3rd 
parties without the user noticing it. Especially the refer header then 
leaks information about the original request to a third party. 
Encryption alone doesn't help.
>> communication can be protected.
Btw. when I read this text at 
https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/#more-7754 
then TLS is used but there is a warning that some parts are not 
retrieved or not secure 
(http://www.iab.org/wp-content/plugins/amr-ical-events-list/css/icallist.css?ver=1) 
:)
>> not yet deployed, and we urge firewall policy administrators to permit
How to get and install the necessary certificates?
>> cleartext payload.  For many of these activities there are no solutions
This seems to be a weak part of HTTP2 and a proxy approach may become 
handy on tackling those.
>> where traffic is confidential by default.
Any help welcome.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 17 Nov 2014 12:56:01 +0000

--------
In message <[email-masked]>, Roland Zink writes:

Actually I think the most important part is this:

>>> Encryption

Will browsers finally stop treating self-signed-certs as if they
were highly radioaktive ?

-- 
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: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 17 Nov 2014 08:13:52 -0500

> were highly radioaktive ?

The situation highlights many problems with the way people think about
security. I have been arguing that browsers should simply accept self
signed certs without comment (or a padlock icon) for years now. Its
like the old AOL/2.0 version of S/MIME 'WARNING THIS EMAIL IS
DIGITALLY SIGNED'.

Security usability is a lot easier than people imagine, it mostly
involves not doing things that are ridiculous.

The security signal in TLS is there to tell the user that the
connection is authenticated. If the connection is only weakly
authenticated or not authenticated then there should be no signal
unless there was some reason (e.g. pinning) to expect better
authentication.

Another area where people go wrong is making security by analogy
arguments in place of a security analysis. The consequences of this
can be seen on all those Web forms where someone has dumped a CAPTCHA
onto the UI for no other reason than to make themselves look clever.

Rather than arguing that 'X is as good as Y which gets the security
signal', folk need to ask if Y should have got the security signal in
the first place.

---

From: Roland Zink <[email-masked]>
Date: Mon, 17 Nov 2014 15:16:52 +0100

> were highly radioaktive ?
Good question. One example is my home router. When I change the name it 
automatically generates a new self-signed certificate. However when 
accessing the UI the browser gives an error message and only brave 
people will probably continue. Others may just fall back to unencrypted 
http.

Roland

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 17 Nov 2014 09:56:39 -0500

On Mon, Nov 17, 2014 at 9:16 AM, Roland Zink <[email-masked]> wrote:
> accessing the UI the browser gives an error message and only brave people
> will probably continue. Others may just fall back to unencrypted http.

It gets worse.

The next stage is when the router manufacturer decides to eliminate
the repeat of the problem by creating a self signed CA cert.

Alice goes to Bob's router and merrily clicks OK to accept the root
cert. Congratulations, in the service of 'protecting' Alice, the
browser has persuaded her to give Bob the ability to sign certs for
any domain whatsoever.

People get very excited about the 50 or so audited CAs in the browsers
and completely ignore the ease of installing a root from an attacker.
The only controls we get is that these roots can't create EV certs and
pinning can prevent attacks.

Out in China, Chu wants to get on a train. To do this she has to use
the state railway authority Web site. And that requires her to install
the state railway authority root.

The solutions to this would be to (1) accept self signed certs with no
security indicator at all instead of the current practice of giving a
conflicted security indicator, first signaling the user is 'safe' with
the padlock, then telling them that they are not state with an idiot
box (the idiot here being the programmer).

(2) when a self signed cert signing cert is installed, the browser
MUST impose a policy constraint on it to only allow it to sign certs
in the domain for which is was presented. So going to
https://www.china-railway.com.cn/ does not cause the browser to be
configured to accept a cert that can sign certs for cnn.com (some
browsers have been fixed, but I don't know they all have).

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 17 Nov 2014 17:39:14 +0100

> browsers have been fixed, but I don't know they all have).

That's exactly what I hate in the "tls everywhere" model : all the
case where no security is expected nor desired will train users to
click on various warning boxes all the day, just like it was a few
years ago. And in order to avoid this, browser vendors will make
their lifes easier and will remove the warning, just play with the
background color of the URL bar. Next step will be that in order to
spoof any HTTPS web site, you'll simply have to emit a self-signed
cert that most users will not even understand as something insecure
provided that it works.

I'm sorry guys, but I *want* to be able to use insecure devices without
my browser pretending that I'm doing something securely when that's not
the case, and I don't want to have to support the hassle of clicking
various warnings to confirm that I really want to connect to my newly
unboxed DSL router.

I've already stated it here a few times, he only way I'm seeing something
reasonable is for browsers to behave like this :
  - no access to a website whose cert is not properly signed, with no
    way to bypass this (eg: no "I accept the risks").
  - self-signed (and only self-signed) allowed for plain IP addresses
    without warning.

As a result, we'll see that devices which need to be configured locally,
or developers machines will run on plain IP addresses. Regular web sites
will deploy https only if they feel capable of dealing with what it implies
(ie: pay for supporting a multi-host cert etc). And after this we'll know
whether the current TLS model really is sustainable for each and every web
site or not. Until this is done, we'll continue to see web sites where
improper certs are delivered such as the main site's cert on various
sub-sites.

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 17 Nov 2014 17:06:37 +0000

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

>That's exactly what I hate in the "tls everywhere" model : 

I think the major mistake in "tls everywhere" is that while the
OSI models protocols sucked, the basic idea of layering did not.

IMO the HTTP/2.0 spec shouldn't mention encryption or TLS with
a single word, making it robust for future changes in transport
or encryption technologies and policies.

By welding HTTP/2.0 to TLS (as hard as they can), the "tls everywhere"
crowd is effectively making it harder to replace TLS with something
better in due time.

---

From: Mike Belshe <[email-masked]>
Date: Mon, 17 Nov 2014 09:50:33 -0800

> crowd is effectively making it harder to replace TLS with something

This is a false claim.  An example would be HTTP binding on top of SCTP.
HTTP didn't define it, but it was defined later in a separate RFC.  It just
takes someone defining how to do it.  Obviously, you have to know what
you're binding to in order to define it.

Defining how to bind HTTP to today's leading secure transport protocol does
not detract from defining how it would be bound to future protocols,
if/when they should emerge.

Mike

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 17 Nov 2014 18:11:10 +0000

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

>if/when they should emerge.

It still belongs in a separate document, so that the linkage is isolated,
explict and visible.

---

From: Jason Greene <[email-masked]>
Date: Mon, 17 Nov 2014 12:09:49 -0600

> On Nov 17, 2014, at 6:56 AM, Poul-Henning Kamp <[email-masked]> wrote:
> 
> --------

Even better would be to support anonymous ECDH. Why bother requiring all of these fake certs to be generated when they have no legit purpose.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 17 Nov 2014 13:29:19 -0500

On Mon, Nov 17, 2014 at 12:50 PM, Mike Belshe <[email-masked]> wrote:
> not detract from defining how it would be bound to future protocols, if/when
> they should emerge.

I have a different concern.

I think that the outcome will be as follows:

1) Mandate use of TLS with HTTP.
2) Decide that using 'full TLS' is too much inconvenience.
3) Browsers race to the bottom weakening the TLS security model to
meet the mandate
4) Bad TLS drives out the good.
5) Net reduction in security.

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 17 Nov 2014 19:59:31 +0100

> 5) Net reduction in security.

Exactly!

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 17 Nov 2014 20:06:21 +0100

> 5) Net reduction in security.

Also do not forget the disruptive impact on transparent caches
everywhere. Mobile phone operators are currently applying caches
to "enhance your experience" (in fact reduce their BW costs), and
doing so on HTTP only is still fine given that https-only traffic
is minimal today. When they'll see their external bandwidth grow
10-fold they'll start to aggressively decipher HTTPS to cache HTTPS
traffic as well. For them it's trivial, they just have to install
their root CA into each smartphone they sell. And at this point
none of the "secure" sites will be secure anymore at these places.

I've long said that trying to put https everywhere is pointless
until there's a reliable and clean method for letting trusted
proxies access the clear text (the famous "GET https://" we've
been talking about for years). Until this happens, people will
have to keep in mind that the internet is driven by economics,
not by ideology.

Willy

---

From: Martin Thomson <[email-masked]>
Date: Mon, 17 Nov 2014 21:52:03 -0800

On Nov 17, 2014 8:14 AM, "Jason Greene" <[email-masked]> wrote:
> Even better would be to support anonymous ECDH. Why bother requiring all
of these fake certs to be generated when they have no legit purpose.

That at least is an easy one to answer. If your handshake looks different
(and any anonymous mode will, unless you use TLS 1.3 and some aggressive
padding), then you open an invitation to MitM. Have them look identical,
and it gets harder to mount an undetectable attack. Not to mention avoiding
code complexity.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 18 Nov 2014 08:11:29 +0000

--------
In message <CABkgnnVWze4YVTfgVc-+9DRTgGdG86xmHbySB=g2uDoyvQ_S=[email-masked]>
, Martin Thomson writes:

>padding), then you open an invitation to MitM. 

This is exactly the kind of crap-think I tried to warn against in
my FOSDEM keynote:

The point was *not* to defend against MitM but pervasive monitoring.

Your attitude there, shared by far too many TLS-heads is like the
parents who forego child immunisations, because their kids might
feel unwell for a couple of days afterwards.

ECDH would do *wonders* against pervasive monitoring, it would render
almost all of NSAs take worthless to them, and you cannot do a MitM
with a passive splitter.

It's the same stupid attitude which makes browsers treat self-signed
certs as radioactive waste.

That attitude, is a BIG part of the problem, and contributes nothing
to the solution for pervasive monitoring.

---

From: Stefan Eissing <[email-masked]>
Date: Tue, 18 Nov 2014 11:06:18 +0100

There is no known technology that covers all use cases and security issues of http. Arguing that tech X is bad because of attack vector Y, is always possible for a significant amount (I think almost all) of use cases.

A discussion has to take the use case first, investigate threats vs. risks and find the most suitable tech. Therefore, differentiation between "browsing the net" and "connecting to a local ip" is helpful.

Discussing mandatory security tech for all uses of http is not. There are more use cases than all of us know combined. If h2 should be a successor of http, forcing tls is not feasible in practise.

I think almost all of us know this use case:
- I myself need a browser that allows me to accept "invalid" security. By choice.
- My mother *should not* have a browser that ever does that, nor should she ever be asked to.
- It would be great if my mother could connect to the DSL box and tell me what possible error she sees there. With a browser that she knows.
- Installing self-signed certs beforehand on all involved systems/trust stores that do not expire before I need them is mission impossible.

//Stefan

> Am 18.11.2014 um 09:11 schrieb Poul-Henning Kamp <[email-masked]>:
> 
> --------

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

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 18 Nov 2014 10:29:18 +0000

--------
In message <[email-masked]>, Stefan Eissing
 writes:

>Discussing mandatory security tech for all uses of http is not. There 
>are more use cases than all of us know combined. If h2 should be a 
>successor of http, forcing tls is not feasible in practise.

You're mistaken:  It is perfectly feasible because HTTP/2.0 is
a layer 9 ("politics") protocol.

HTTP/2.0 is being deliberately crippled to further certain political
agendas, notably "TLS everywhere", despite the fact that this will
handicap adoption of the protocol in the network.

In particular, HTTP/2.0 is being sold as delivering "speed" and
"privacy" while in reality it does neither for the vast majority
of all websites.

The speed only happens if you have a global CDN, otherwise the
3*RTT overhead of the mandatory TLS will kill your speed.

The users will still be tracked and have their identities deconstructed
across the web, because that is the business model of major the
HTTP/2.0 proponents.

But HTTP/2.0 is still being rushed through the IETF process for
political reasons, even though its technical quality leaves so much
to be desired that serious talk about HTTP/3.0 started long time
before HTTP/2.0 even made it to WG Last Call.

The fact that HTTP/2.0 is deemed ready for IETF Last Call, without
a single published benchmark showing what performance can be obtained
on commodity server hardware is not accidental:  It doesn't matter
to its backers, their goals are only political.

---

From: Mike Belshe <[email-masked]>
Date: Tue, 18 Nov 2014 06:48:33 -0800

On Mon, Nov 17, 2014 at 10:11 AM, Poul-Henning Kamp <[email-masked]>
wrote:

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

There is no need for that.  We don't need a separate document to define the
binding to TCP, and we don't need a separate document to define the binding
to TLS.  But we've been over this too many times before.

I will mute PHK again now; so don't interpret my lack of reply as tacit
agreement.

Mike

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 18 Nov 2014 14:56:16 +0000

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

>We don't need a separate document to define the
>binding to TCP,

Probably not, as no policy restrictions is put on the binding.

> and we don't need a separate document to define the binding
>to TLS.  

Yes you do, because we're no up to several pages of text trying
to force all sorts of policy restrictions onto the TLS+HTTP/2.0
combination.

---

From: Jason Greene <[email-masked]>
Date: Tue, 18 Nov 2014 10:06:30 -0600

> On Nov 17, 2014, at 11:52 PM, Martin Thomson <[email-masked]> wrote:
> 
> 
> That at least is an easy one to answer. If your handshake looks different (and any anonymous mode will, unless you use TLS 1.3 and some aggressive padding), then you open an invitation to MitM. Have them look identical, and it gets harder to mount an undetectable attack. Not to mention avoiding code complexity.

Thats pretty small advantage. Self signed certs are easily detected and decoded by anyone in a position to MITM.

Anyway I thought the point was to replace plain text communication where possible, and that requires addressing the non-authenticated case, which this IAB statement even refrerences.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 18 Nov 2014 17:21:37 +0100

> Thats pretty small advantage. Self signed certs are easily detected and decoded by anyone in a position to MITM.

Yes.  In fact, someone who works at a pretty large vendor stood up at
the Zürich interim meeting and said that his product was doing just this.

> Anyway I thought the point was to replace plain text communication where possible, and that requires addressing the non-authenticated case, which this IAB statement even refrerences.

Yes.  If anything, this group has led in efforts to use as much
encryption as possible.  The big question before you is really whether
you agree with the concerns that PHB and Will Chen have separately
raised, about whether anonymous encryption would cause people to not
deploy The Real Thing.  My crystal ball tells me that this is less of a
concern than any interoperability problems we might see due to poor
crypto algorithm agility.  That is something that we as a community need
to work on (and not just the browser folk).

Eliot

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 20 Nov 2014 15:13:49 +1100

The problem I have with TLS everywhere is reflected by this part:

> must have in the Internet
>

It is a false promise that by encrypting all our application layer
protocols that we will suddenly provide adequate security for internet
users.
It is simply not the case that encryption provides a sufficient protection
of a users "private information" to achieve any significant increase in
trust.

Protocol encryption does not protect any meta data.   Observation of
encrypted traffic can still be used to work out when, where, to who of your
internet usage.   By simple correlation of sizes and timing, very good
predictions of what you have read to who you have communicated to on the
other side of the server.

I think that pretending that TLS is a panacea that will somehow make the
public internet a safe private network is just wasting effort that would be
better spent really trying to fix the problem.      Making the problem of
privacy on a public network the problem of every protocol designer is
hoping for some kind of emergent behaviour that is just not going to happen.

There are still people today hoping on flights to Nigeria with all their
life savings in their suitcase, hoping to help some dude they only met via
email import export millions of dollars.    Adverts based on my search
terms still pop up on other related computers,  thus revealing to my wife
what birthday present I'm searching for. Oppressive regimes still know
which websites you visit even if you use https.  Encrypting  is not going
to help with any of these problems and they are the kinds of problems that
need to be fixed if you want people to trust the internet.

regards

-- 
Greg Wilkins <[email-masked]>  @  Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: Tim Bray <[email-masked]>
Date: Wed, 19 Nov 2014 20:24:37 -0800

On Wed, Nov 19, 2014 at 8:13 PM, Greg Wilkins <[email-masked]> wrote:

You’re mostly right, but here’s where you’re wrong:

> ​​
> ​​
>  Encrypting  is not going to help with any of these problems
> ​
>

​Yes, it will *help*. No, it will not ​*solve* them, and solving them is
important, but providing help now is a good thing to do.  Every layer of
privacy technology drives attacker costs up and makes certain attacks
non-economic.  I for one am not willing to put improvements on hold for
years while we strive for the perfect at the expense of the good.

​​

​​

-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 20 Nov 2014 07:12:59 +0100

On Wed, Nov 19, 2014 at 08:24:37PM -0800, Tim Bray wrote:
> You???re mostly right, but here???s where you???re wrong:
> 
> > ??????
> > ??????
> > ???
> ???Yes, it will *help*. No, it will not ???*solve* them, and solving them is
> important, but providing help now is a good thing to do.

No it will not help. It confuses users, and the *only* way to help is
to make it very clear to them whether they're safe or not. It's not by
saying "it's almost safe" that you'll help them. People using public
WiFi at cafes believe they're surfing without anyone knowing what they're
doing because they see a nice green pattern in their URL bar, yet they
don't even know that everyone around knows what site they're surfing
and that based on the MAC you can even classify who does what when
multiple users do the same in parallel.

Internet protocols are complex and the details are not easy to understand
for the non-tech people. Continuously telling them "don't worry, if you
see a green lock it means nobody can see what you're doing" is a lie and
just trains them never to wonder. Users need to be taught reality first,
and once they're aware of the risks it becomes possible to offer various
protection grades. If you do it the reverse way it will be even more
complicated for them to know when it's safe and when it's not.

At minima, there could be a help box in browsers saying what is visible
and what is not, for each connection :

   Do people around me see what site I'm surfing Yes/No
   Do people around me see the contents I'm retrieving/sending Yes/No
   May people around me pretend to be the website and see everything I do Yes/No
   Does the network administrator see what site I'm surfing Yes/No
   Does the network administrator see the contents I'm retrieving/sending Yes/No
   May the network administrator pretend to be the website and see what I do Yes/No
   Does the network administrator have a way to recognize me next time Yes/No
   Does the website have a way to recognize me next time Yes/No
   Does the website know where I am located Yes/No
   Does the website have more info about me Yes/No
   Do third party web site know what I'm seeing on this web site Yes/No

etc...

Depending on clear/encrypted/self-signed/authenticated, and same for proxies,
the results above will change and may already surprize a huge number of users.

Willy

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 20 Nov 2014 17:45:35 +1100

> years while we strive for the perfect at the expense of the good.

Tim,

if the problem is to make users regain trust that their private data is
safe, then anything that *not solves* the problem while trying to appear to
actually makes the trust problem worse.

So I'm totally fine with saying "Use TLS because it will protect you from
revealing your passwords, bank accounts, and other data you send to anybody
but the server (who we assume you trust with all that stuff)".

I'm not fine with saying "Use TLS because it will protect your privacy when
using the internet".

To be blunt, many if not most privacy concerns come from either end of the
connection: either somebody sending you a convincing Phish or the server
does something they should have with your data.   Many of the man in the
middle privacy attacks work on just meta data.

So by all means, let's use encryption and encourage its use.  But let's not
pretend it provides anything more than encryption - which is neither
privacy nor trust.

cheers

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 20 Nov 2014 20:32:19 +1300

On 20/11/2014 7:45 p.m., Greg Wilkins wrote:
> On 20 November 2014 15:24, Tim Bray wrote:
> 
>> ​​
>>> Encrypting  is not going to help with any of these problems ​
>>> 
>> 
>> ​Yes, it will *help*. No, it will not ​*solve* them, and solving
>> them is important, but providing help now is a good thing to do.
>> Every layer of privacy technology drives attacker costs up and
>> makes certain attacks non-economic.  I for one am not willing to
>> put improvements on hold for years while we strive for the
>> perfect at the expense of the good.
>> 

Encryption-everything/everywhere is politics and security theatre. It
has a lot of collateral damage from the warning popups, false signals
claiming privacy, actively revealing details otherwise private, and
the false sense of security provided to developers implementing things
on top of it.

When the goal is to improve *trust* collateral damage is simply not
acceptible.

Crossing the fine distinction of "everything" versus "when
appropriate" is the same mistake NSA etc are trying to recover from.
They accepted collateral damage and got caught at it. I have no doubt
the system they implemented provided a high degree of *security* for
their citizens. While actively *destroying* the basis for trust in the
process.

I have not seen anyone objecting to actual improvements. Just fighting
against what appears to be responses based in blind panic or blinkered
idealism.

Lets cool down on the "encrypt, encrypt, encrypt!" bandwaggon and
actually *do* the encryption in ways that can be shown to improve the
network without collateral damage.

Amos

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 20 Nov 2014 19:00:45 +1100

Folks,

I asked people to have a read and be aware of the greater context, not to re-start the debate. We’re going to be shipping H2 shortly; we’ll deal with what IETF LC and IESG review bring when they come.

Cheers,

> On 14 Nov 2014, at 11:01 pm, Mark Nottingham <[email-masked]> wrote:
> 
> Everyone,
>