Subject: Re: https at ietf.org

From: [email-masked] (Noel Chiappa)
Date: Thu, 7 Nov 2013 12:19:00 -0500 (EST)

> From: [email-masked]

    > In light of the sentiments expressed at the plenary and in perpass in
    > regards to opportunistic encryptions, perhaps this is the dogfood we
    > should be eating.

Yes, encrypting publicly available documents will do so much to increase our
privacy.

Look, I've got nothing against increasing privacy, but encrypting everything
is neither a privacy panacea, nor without costs/hassles.

E.g. Wikipedia now insists on sending me to HTTPS: versions of _all_ their
pages (I guess to protect against a MITM corrupting the content - since the
content is totally public, I can't figure out what else good they think it
does - although HTTPS doesn't really do that good a job at that). Problem is
that for one of my browsers, it somehow can't get the certificates right, so
every time I go to Wikipedia I get a zillion pop-ups complaining about
certificate problems. Irony is, of course, that in some counties the whole
site is just plain totally blocked.

That's just an _example_ of the downside of 'encrypt everything, all the
time'.

And I can't wait until national governments start deciding that 'encrypt
everything, all the time' violates their sovreignty, and they start blocking
encrypted content from crossing their borders...

	Noel

---

From: Dave Cridland <[email-masked]>
Date: Thu, 7 Nov 2013 17:28:29 +0000

> Yes, encrypting publicly available documents will do so much to increase
That's not what Ned or I was hinting at.

RFC 2817 describes a mechanism for connecting on port 80, and asking the
server nicely to switch to TLS, rather than connecting on port 443 and
switching to TLS from the outset.

It's the equivalent of the majority of protocols, which support a
"STARTTLS" or similar extension, making it trivial to provide and use
optional, opportunistic, encryption.

What this would allow is that browsers could *easily* use TLS to provide
some protection, even when given an "http" scheme URI.

Dave.

---

From: Tim Bray <[email-masked]>
Date: Thu, 7 Nov 2013 09:47:42 -0800

On Thu, Nov 7, 2013 at 9:19 AM, Noel Chiappa <[email-masked]>wrote:

> pages (I guess to protect against a MITM

No, Wikipedia is taking the position that it’s nobody’s business who’s
reading about what, aside from the person doing the reading. For example, a
gay teenager in Uganda can read about potential health problems with
greatly lessened fear of exposure and torture.  I heartily approve. -Tim

> corrupting the content - since the

---

From: Yoav Nir <[email-masked]>
Date: Thu, 7 Nov 2013 17:48:57 +0000

On Nov 7, 2013, at 9:19 AM, Noel Chiappa <[email-masked]> wrote:

> does - although HTTPS doesn't really do that good a job at that).

The content of Wikipedia is public, and if the people at [insert favorite government agency] or at your IT department would like to browse it, they are welcome to it. This is not an issue of protecting Wikipedia's privacy. The issue here is protecting what you are looking at. Your IT department might take a dim view of the kinds of articles that you read, and the government agency might think you either a threat or a good target for blackmail if they know the kind of articles that you read.

---

From: [email-masked]
Date: Thu, 07 Nov 2013 11:10:57 -0800 (PST)

> Yes, encrypting publicly available documents will do so much to increase our

;-)

> is neither a privacy panacea, nor without costs/hassles.

I agree 100%.

> does - although HTTPS doesn't really do that good a job at that).

Insisting on encryption != opportunistic encryption. And yes, if they require
it, that's bad for exactly the same reasons it would be bad for the IETF to do
so.

> Problem is

Exactly right. But if we can do it in a way that causes those with the ability
to upgrade to an encrypted connection to do so, that's not a bad thing.

				Ned