Subject: Pervasive encryption: Pro and contra

From: Tim Bray <[email-masked]>
Date: Sat, 16 Nov 2013 17:03:41 -0800

There has been a *whole lot* of traffic on this subject.  It’s fascinating
that the meeting of minds is so difficult, and any possibility of that
happening is made more difficult by the discussion skewing back and forth
across the road.

To help sort things out in my own mind, I just went and read the last few
hundred messages and attempted to curate the pervasive/mandatory encryption
arguments, pro and contra.  It’s in a Google doc that’s open to comment by
anyone: http://goo.gl/6yhpC1  Hm, is there a handy wiki platform somewhere
that can stand up to the pressure?

I don’t know if trying to organize the talking points is generally useful,
but I sure found it personally useful; maybe others will too.

Disclosure: I remain pretty strongly in favor of as much mandatory
encryption as we can get, so that may have filtered my expression of the
issues.  I've version-stamped this: 2013/11/16, and promise not to change
it in case people comment on it.

---

From: Tim Bray <[email-masked]>
Date: Sat, 16 Nov 2013 20:27:55 -0800

Um, I see some debate on the issues breaking out in the comments.  I’m not
the chair, but if it were, I’d holler at you to have those arguments here;
I made sure that every bullet point in that doc had an unambiguous address,
so you can say in email that “C2.4 isn’t a problem because...”  My goal was
to propose a candidate structure to have the debate around, not an
alternate place to have it.

On Sat, Nov 16, 2013 at 5:03 PM, Tim Bray <[email-masked]> wrote:

> anyone: http://goo.gl/6yhpC1  Hm, is there a handy wiki platform
> somewhere that can stand up to the pressure?
>

---

From: SM <[email-masked]>
Date: Sat, 16 Nov 2013 22:15:27 -0800

At 17:03 16-11-2013, Tim Bray wrote:
>There has been a *whole lot* of traffic on this subject. It's 
>fascinating that the meeting of minds is so difficult, and any 
>possibility of that happening is made more difficult by the 
>discussion skewing back and forth across the road.

Thanks for trying to list the pros and cons.

>To help sort things out in my own mind, I just went and read the 
>last few hundred messages and attempted to curate the 
>pervasive/mandatory encryption arguments, pro and contra.  It's in a 
>Google doc that's open to comment by anyone: 
>http://goo.gl/6yhpC1  Hm, is there a handy wiki platform somewhere 

See http://trac.tools.ietf.org/wg/httpbis/trac/wiki

Regards,
-sm

---

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

In message <[email-masked]>
, Tim Bray writes:

>arguments, pro and contra.  It's in a Google doc that's open to comment by

It's a good topline summary.

I would add:

C6.5:  Pervasive encryption will be defeated by the agencies tasked with
       performing pervasive surveillance:  It's their job.

C6.6:  Pervasive encryption runs a very big risk of being out-lawed, if
       it makes pervasive surveillance impossible.

(And before any USAnians flash the "1st ammendment" card:  Yes, you
have a constitutional right to say any damn thing you want, but not
to encrypt it, in particular not if the "national security" flag
is waved.)

-- 
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: Robert Collins <[email-masked]>
Date: Sun, 17 Nov 2013 21:45:23 +1300

C5.2 It’s unethical to insert encryption into people’s connections
without their consent.
This has an inverse:
P3 : It's unethical to have presumed-private conversations not be

Arguably to P1 (protection) : this is about expectations of users.

-Rob

On 17 November 2013 14:03, Tim Bray <[email-masked]> wrote:
> issues.  I've version-stamped this: 2013/11/16, and promise not to change it
> in case people comment on it.

---

From: Bruce Perens <[email-masked]>
Date: Sun, 17 Nov 2013 00:56:48 -0800

Tim,

I would add "Ubiquitous encryption chaffs the internet. Those of us
who are responsible to manage networks will have a diminished
ability to isolate pernicious traffic among all of the chaff.

I am particularly concerned about traffic from apps not in my
control on my own network.

---

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

I think C1.1 (in the second list, oops, first list shouldn’t be numbered)
covers that.

On Sun, Nov 17, 2013 at 12:56 AM, Bruce Perens <[email-masked]> wrote:

>  Tim,
>
> I would add "Ubiquitous encryption chaffs the internet. Those of us who
> are responsible to manage networks will have a diminished ability to
> isolate pernicious traffic among all of the chaff.
>
> I am particularly concerned about traffic from apps not in my control on
> my own network.
>
>

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Sun, 17 Nov 2013 10:44:40 +0100

Le Dim 17 novembre 2013 02:03, Tim Bray a écrit :

Re: Developers suck, they’re going to leak information anyhow due to
simple error, so transport-level encryption is useless

What I actually wrote is that transport encryption makes the authors of
such mistakes effectively unaccountable to users. A transport that can be
inspected has the same positive properties as open-source code (and people
do inspect weird behaviour when they can)

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Sun, 17 Nov 2013 13:16:45 +0100

> but I sure found it personally useful; maybe others will too.

Also

> Pervasive surveillance occurs at endpoints, so transport-level encryption
> is useless.

1. not useless, but of very limited effect

2. it's disingenuous to claim tackling pervasive surveillance when nothing
is done for the cookie networks whose sole aim is pervasive surveillance
and which *are* an http "feature" (unlike TLS which is being bolted on)

-- 
Nicolas Mailhot

---

From: Yoav Nir <[email-masked]>
Date: Sun, 17 Nov 2013 16:20:05 +0200

On 17/11/13 2:16 PM, Nicolas Mailhot wrote:
> 2. it's disingenuous to claim tackling pervasive surveillance when 
> nothing is done for the cookie networks whose sole aim is pervasive 
> surveillance and which *are* an http "feature" (unlike TLS which is 
> being bolted on) 
True, but all previous attempts to make cookies better have failed.

  * The httpstate working group closed without standardizing "cake"
  * Recent attempts to get websec to discuss next generation cookies
    also failed to get people (especially browser vendors) interested.

Granted, the main aim of those attempts were to protect against cookie 
stealing, but there was also a desire to change the rules of sending 
cookies around.

I'm afraid, though, that we've come to expect web pages to have a bunch 
of faces of all our facebook friends who "like"-ed this article, and you 
need state sharing to get this to work.

Anyway, if you'd like to work on a new HTTP state mechanism with new 
rules and have some idea how to get the content providers and social 
networks to agree to work with it, you're welcome to propose a BoF. I 
promise to hum in favor.

Yoav

---

From: Mike Belshe <[email-masked]>
Date: Sun, 17 Nov 2013 07:46:54 -0800

No, this is a pro not a con.  It is unethical for us to ship unsecure
software.   http without tls is fundamentally below the bar of basic, known
best practices.

---

From: Mike Belshe <[email-masked]>
Date: Sun, 17 Nov 2013 07:48:31 -0800

'runs a risk of' is not a pro or con.

Mike
On Nov 17, 2013 12:18 AM, "Poul-Henning Kamp" <[email-masked]> wrote:

> In message <
> [email-masked]>
> , Tim Bray writes:
>

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 17 Nov 2013 15:49:13 +0000

So you seem to be assuming mnot's plan, and not the variant
where http:// URIs in HTTP/2.0 use non-authenticated TLS.
I still prefer that latter, which has more pros and fewer
cons I think, though its details need to be figured out.

My take:

Add:

P3: Firesheep.

P4: Security that is more than just MTI is much more likely
to be tested and have fewer interop problems that if the
same mechanisms are optional.

P5: Belshe's comment: the more security is built-in the less
you need to ask the user about.

Cheers,
S.

---

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

> P3 : It's unethical to have presumed-private conversations not be

Just like their phone lines, I don't think people presume that their
internet conversations are *technically* difficult to eavesdrop by
government or resourceful criminals. People presume the exact
opposite.

Is HTTP/2.0 going to promise people that their conversations are now
unbreakable? Who is in the position to make that promise? How in the
world do we even know that TLS isn't broken by someone who does not
publish their findings?

Zhong Yu

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 17 Nov 2013 15:57:43 +0000

On 11/17/2013 03:54 PM, Zhong Yu wrote:
> unbreakable?

Terms like unbreakable are irrelevant here. Anyone who makes any
such claim, or uses any such claim to argue anything, is talking
nonsense from a security point of view.

Neither the opponents of, nor proponents for, more use of TLS
gain anything with such bogus arguments.

S.

---

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

You are right. I used an inappropriate word, you spotted it and my
whole argument collapses.

So, what are we going to tell people about the security of HTTP/2.0?

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 17 Nov 2013 16:07:54 +0000

> So, what are we going to tell people about the security of HTTP/2.0?

First, I'd tell them not to take everything they've seen on this
list in the last few days as being authoritative. The ramifications
of the current plan are still being figured out as far as I can
see.

And then *after* that is figured out, you could tell them about the
security of HTTP/2.0. In other words, its probably a bit early to
be writing the user guide:-)

S.

---

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

In message <CABaLYCuBgBZWZR1dY7_mkHVSrLBncyb=[email-masked]>

>'runs a risk of' is not a pro or con.

First, I wrote "runs a very big risk of", and second I have a very
hard time wrapping my head around how an IETF WG could consider that
a "pro" argument, so please enlighten me ?

---

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

In message <[email-masked]>

>software.   http without tls is fundamentally below the bar of basic, known

Bull-shit.

It may be below your personal political point of view, but I have
yet to hear one single porn-site say that lack of encryption is
below their standard.

That's only funny until you remember that they and they move about
30% of the HTTP bytes on the net.

Furthermore, television is being "de-cabled" and I have yet to hear
any of them wanting to first expend effort on DRM encryption and then
wrap that in an extra layer of encryption because it would be
"below the bar" for somebodys "best practice".

HTTP/2 is a protocol Mike, it is not a policy.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 17 Nov 2013 21:07:43 +0100

>a "pro" argument, so please enlighten me ?

I understood the comment as saying that the point does not belong on
a "pro and contra" list, which seems fair enough in this instance. 
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 17 Nov 2013 20:13:06 +0000

In message <[email-masked]>, Bjoer

>a "pro and contra" list, which seems fair enough in this instance. 

Why is having your protocol banned in USA or China not a "con" ?

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 17 Nov 2013 21:47:28 +0100

>Why is having your protocol banned in USA or China not a "con" ?

If "pervasive encryption" was outlawed and lawmakers asked me to explain
the pros and the cons of it, I would not list the legal status as a con,
I would consider that besides the point. Talking to others I would note
it's not a legal option. I think it's fair to say

  Contra:
    - Not an option.

would be a bit strange, all the more so if it was

  Contra:
    - Could become not a legal option.

as that is true for everything.

I also think the argument is flawed. Consider two scenarios:

  A: We encrypt only the most sensitive top 1% communications.
  B: We encrypt everything except the most sensitive top 1%.

In which scenario is encryption more likely to be outlawed? I believe
people would find it strange if pervasiveness was the deciding factor.
It seems more likely that governments would attack elsewhere, such as
mandating digital repression mechanisms on licensed devices.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

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

> Why is having your protocol banned in USA or China not a "con" ?

TLS has not been banned in either China nor the USA.  You claim there is a
"risk" of that, but that's just an opinion, and not one we'll ever likely
agree on.

So, for this list, I was recommending we stick to objective criteria.

Mike

---

From: Mike Belshe <[email-masked]>
Date: Sun, 17 Nov 2013 13:07:48 -0800

On Sun, Nov 17, 2013 at 12:03 PM, Poul-Henning Kamp <[email-masked]>wrote:

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

You're missing the point, PHK.  Someone added a "con" to the list that it
is somehow unethical to use TLS.  I disagree with that opinion, and was
simply countering it with a bit of sarcasm.

I doubt we have agreement on what is ethical or not in this protocol with
relation to using TLS.  But in my opinion, it is definitely not unethical
to encrypt the protocol.  There are plenty of protocols and applications
that encrypt without your choice.

So I propose we drop these silly opinion statements from the pro/con list.

The only difference between us, PHK, is that you're advocating a POLICY of
opt-in security. I'm advocating a POLICY of opt-out.  Neither of us is
proposing taking away TLS nor taking away unencrypted HTTP.

Mike

---

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

In message <[email-masked]>, Bjoer

>the pros and the cons of it, I would not list the legal status as a con,

I'm sorry, your argument really makes no sense to me.

We don't get to decide if there will be pervasive encryption or
not, politicians decide that.

If we define a protocol which makes it impossible for goverment
snoops to do what the law says their job is, our shiny new protocol
will be broken or banned.

Our WG's mandate is to improve HTTP performance, a banned protocol is
not going to be a performance improvement.

Don't get me wrong, I'm as worked up about the Global Privacy
Elimination as you are, but I know enough about politics to realize
that we won't change that via protocol design.

If you don't belive that, look at what they did with Skype (which
allegedly was a secure protocol initially):  They paid first eBay
and subsequently Microsoft to buy it, to be able to break it open.

Of course, if you want HTTP/2.0 to be a political statement by
forcing politicians to ban it, we don't need to waste all this time
thinking about optimization, compression and performance, we should
instead concentrate the design effort on making it maximally obnoxious
for NSA, GCHQ &c.

If that is the goal, we should have started with TOR, rather than SPDY.

---

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

In message <CABaLYCvJ8wG9k6kJpxrnEX4EGBVHh2J1XLPwJFH_+n+Q=[email-masked]>
, Mike Belshe writes:

>TLS has not been banned in either China nor the USA.

Only because they found a smarter thing to do:

They subverted the CAbal and let everybody think they had privacy,
when in fact they have no such thing.

The even went as far as try to get the world to use an "Unsafe as designed"
NIST approved crypto algorithm, and despite the funny smell, the world did.

---

From: Bruce Perens <[email-masked]>
Date: Sun, 17 Nov 2013 13:26:21 -0800

On 11/17/2013 01:07 PM, Mike Belshe
wrote:

Someone added a "con" to the list that
it is somehow unethical to use TLS.

Not unethical to use it where appropriate. Both unethical and
ultimately damaging to society to use it when it isn't strictly
necessary. To do so:

* Ultimately damages the operation of the internet by making caching
and other legitimate manipulations of HTTP impossible.

* Reduces the freedom of people to control their own networks in the
face of possibly-hostile applications in their own devices, by
chaffing their private networks.

* Makes more difficult the job of police and intelligence agencies
that have an actual responsibility to protect us.

The problem of surveilance is a political one, and should be dealt
with politically. For us to make the job of police and intelligence
agencies more difficult arbitrarily and without any _public_ mandate
to do so is, I think, on a range between immature and criminal.

But, you say, you're just trying to protect people! It's not that
easy.

Folks, whether we technically enable inappropriate use of
surveilance or hinder appropriate use of surveilance, we end up with
blood on our hands either way. If we are not involved in the
_political_ process around this issue, and do not work to find a
balance there, we have little to excuse us.

Thanks

Bruce

---

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

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

>opt-in security. I'm advocating a POLICY of opt-out.

No, you are attempting to eliminate the policy of opt-out.

Today privacy or not is a policy decision in the hands of content
writers who get to choose if they write "http://" or "https://" in
their links.

You want to take that policy choice away from them, by changing
the semantics of "http://" under their feet.

If you start deploying a main-stream browser now, which heuristically
attempts HTTPS when it sees "http://", you're going to kill so many
sites performance that you will become the most hated man on the web.

And remember:  We don't deliver policies, we deliver tools.

---

From: Mike Belshe <[email-masked]>
Date: Sun, 17 Nov 2013 13:41:34 -0800

On Sun, Nov 17, 2013 at 1:27 PM, Poul-Henning Kamp <[email-masked]>wrote:

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

No I am not.  Insecured HTTP is here to stay.  I have not proposed
otherwise.

But as usual, you miss the point.

The point is that you called me out for advocating policy, and that is
fine.  I just want you to realize you are advocating policy as well - you
believe a POLICY that http should be unencrypted.  So much for your "tools
not policies" silliness.

> the semantics of "http://" under their feet.

HTTP does its versioning under the hood.  Upgrading from HTTP/1 to HTTP/1.1
is not under control of the content writer and never has been.  It's up to
the control of the server administrator.  The exact same thing is true for
HTTP/2.

> sites performance that you will become the most hated man on the web.

Already exists, dude, and its faster :-)   But I seriously doubt I'll ever
take that title away from you.

This will be my last reply.

Mike

---

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

In message <CABaLYCt6+MtWjw3mp2fknFvSQGo520=[email-masked]>
, Mike Belshe writes:

>I just want you to realize you are advocating policy as well - you
>believe a POLICY that http should be unencrypted.

Yes, I do belive that.

And I belive that because we have spent almost 20 years teaching
people that if they want encryption they should spell it "https:"
rather than "http:".

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Sun, 17 Nov 2013 23:11:52 +0100

> Arguably to P1 (protection) : this is about expectations of users.

User expectations are broken right and left by websites. The url claims
they access a particular entity but in fact half the web site is
constructed from stuff hosted elsewhere, usually for plugging in as many
paying data collection schemes as possible.

3 out of 4 times one of our users requests his access logs his immediate
and horrified response is "but I didn't go there!" (and of the remaining
25% percent most don't answer so I have no idea of what they think of
their logs)

-- 
Nicolas Mailhot

---

From: Roberto Peon <[email-masked]>
Date: Sun, 17 Nov 2013 14:20:21 -0800

Tim-
I read the doc, and though I disagree with most of the items, I also want
to thank you for putting it together so we have something concrete to
debate with/around.

There are a number of things within the document that I disagree with, the
first being the name.
We could entitle it "awesome incremental privacy" and it would still mean
the same thing, with completely different coloring.
There are a number of other colorings in the document that vary widely from
the "color" of objective statements.

Another doc that we should probably talk about, since we apparently can't
avoid it is:
http://tools.ietf.org/html/draft-vidya-httpbis-explicit-proxy-ps-00 and
so we might also want to read that one (bleh.. more reading, I know... I
know...)
The document there talks extensively about the intermediaries, the problems
they solve and face, and the problems that end-users and sites face.

While making hypothesis about the 3rd order effects of encryption on
politics is interesting, but... I don't care for it:
  We could argue endlessly about it and never reach a conclusion, and we'll
only be able to get data about it after we take a course of action... so
that is not helpful.
Discussing politics seems like a poor foundation for an engineering
discussion.

In terms of engineering, we know that:
  today is that there is pervasive monitoring, and that some of this
monitoring includes entities with malicious intent (i.e. criminals).
  users do care about privacy: they want to choose what is public and what
is not; They don't want their lives damaged or destroyed when they have
been doing only legal activities online
  sites do care about privacy: they want to retain the trust of their users
  we have the technical capability to help solve this problem with either
opt-in or opt-out decisions made by either the server or client.
  various jurisdictions have varying tolerance for encryption, and both
opt-in or opt-out mechanisms allow this to be accommodated
  users don't have the technical depth to understand what is necessary to
achieve privacy, let alone security.
  education and communication about technical issues is extremely difficult
and takes significant time, if possible at all
  we cannot effectively impose changes on already deployed infrastructure
or content

-=R

---

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

I think Poul's argument is that P1 and P2 are simply invalid. He wrote
an article for that. If they are listed as pros, we need cons to
counter them.

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Sun, 17 Nov 2013 23:33:54 +0100

>     also failed to get people (especially browser vendors) interested.

What was wrong with the solution that was proposed on this list a few
months ago ? (by PHK IIRC)

Regards,

-- 
Nicolas Mailhot

---

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

+1

Is anyone here from RIM?  It would be interesting to get their 
perspective on this, having lived it in India.

Adrien

------ Original Message ------
From: "Bruce Perens" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 18/11/2013 10:26:21 a.m.
Subject: Re: Pervasive encryption: Pro and contra
>On 11/17/2013 01:07 PM, Mike Belshe wrote:
>>
>>Someone added a "con" to the list that it is somehow unethical to use 
>>TLS.
>face of possibly-hostile applications in their own devices, by chaffing 
>their private networks.
>* Makes more difficult the job of police and intelligence agencies that 
>have an actual responsibility to protect us.
>
>The problem of surveilance is a political one, and should be dealt with 
>politically. For us to make the job of police and intelligence agencies 
>more difficult arbitrarily and without any _public_ mandate to do so 
>is, I think, on a range between immature and criminal.
>
>But, you say, you're just trying to protect people! It's not that easy.
>
>Folks, whether we technically enable inappropriate use of surveilance 
>or hinder appropriate use of surveilance, we end up with blood on our 
>hands either way. If we are not involved in the _political_ process 
>around this issue, and do not work to find a balance there, we have 
>little to excuse us.
>
>     Thanks
>
>     Bruce

---

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

On Sat, Nov 16, 2013 at 5:03 PM, Tim Bray <[email-masked]> wrote:
> There has been a *whole lot* of traffic on this subject.  It’s fascinating that the meeting of minds is so difficult, and any possibility of that happening is made more difficult by the discussion skewing back and forth across the road.
> 
> To help sort things out in my own mind, I just went and read the last few hundred messages and attempted to curate the pervasive/mandatory encryption arguments, pro and contra.  It’s in a Google doc that’s open to comment by anyone: http://goo.gl/6yhpC1  Hm, is there a handy wiki platform somewhere that can stand up to the pressure?
> 
> I don’t know if trying to organize the talking points is generally useful, but I sure found it personally useful; maybe others will too.
> 
> Disclosure: I remain pretty strongly in favor of as much mandatory encryption as we can get, so that may have filtered my expression of the issues.  I've version-stamped this: 2013/11/16, and promise not to change it in case people comment on it.

Thanks, Tim.  I'd encourage you to submit that as an individual (for now) I-D. If you want space to work on it / collect issues, I can give you a repository over on github.

I'd also encourage you to move it quickly past a simplistic "pro/con" model. There are a remarkable number of facets to this discussion, with many interdependencies.

For example, your C1 ("Intermediation") assumes that we won't change that aspect of HTTP, yet there is already a parallel discussion about doing so. Likewise, there are parallel discussions about improving the CA system, crypto algorithms, etc. (C2).

Then,

On 17/11/2013, at 3:27 PM, Tim Bray <[email-masked]> wrote:

> Um, I see some debate on the issues breaking out in the comments.  I’m not the chair, but if it were, I’d holler at you to have those arguments here; I made sure that every bullet point in that doc had an unambiguous address, so you can say in email that “C2.4 isn’t a problem because...”  My goal was to propose a candidate structure to have the debate around, not an alternate place to have it.

... and fresh off a plane, I'm catching up with e-mail; what fun.

Folks, this document is not a WG product, discussion there has absolutely no bearing whatsoever. So, feel free to send bits that way (we've got plenty over here), but realise that they don't count.

Later on,

> See http://trac.tools.ietf.org/wg/httpbis/trac/wiki

If Tim wants to collect input, there are much better tools for doing so. Please don't do it there.

Cheers,

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

---

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

> months ago ? (by PHK IIRC)
Nothing wrong. We also had proposals from Adam Barth ("Cake"), from PHB 
("HTTP Session Management"), Trevor Perrin ("smart cookies"), and Nico 
Williams ("session continuation").  There's really no shortage of 
proposals on how to make cookies better.

What we are lacking is the indication that implementations (especially 
browsers) would implement such a mechanism if we standardized it. There 
is the channel-id proposal that may make cookies harder to steal, but 
that doesn't address its usage at all. With that, it's difficult to get 
people excited enough to actually do the work of reviewing this.

Yoav

---

From: Henry Story <[email-masked]>
Date: Mon, 18 Nov 2013 10:10:26 +0100

Hi Tim,  hi all. 

   Since my days at Sun Microsystems working with Tim Bray I have been developing with 
a loose knit distributed community a set of standards based tools that show how one can
answer a lot of the negatives put forward here in order to build a more secure web with
pervasive TLS based encryption. The idea is to use tools and standards that exist off
the shelf. 

   The answer is to distribute data to the nodes, so that each person/organisation physically
controlls its own information on its servers. This requires distributed authentication and
distributed access control. It requires ease of use. All of that can in fact be achieved in
my opinion.

  I can explain this here. But most of you will find something annoying about it.
Tim will be skeptical because we use RDF. Others will be skeptical because we
use client side TLS certificiates for identification without using CAs to sign them, 
....  I think the pain point makes it worth trying something new.

  you can check the list of specs we use
   https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index.html

  But of course that won't help that much. You have to see it in action to see it 
working. 

   If some of you are in Paris next week we'll be having a Workship at the Mozilla labs
in Paris to show how that works.
   https://github.com/stample/wiki/wiki/Weave-the-web-we-want

  if you can't read the doc, then check out the project README to get an idea 
of how this works ( with curl: you'll need to imagine it doing the same with JS )
   https://github.com/stample/rww-play

Henry

> Disclosure: I remain pretty strongly in favor of as much mandatory encryption as we can get, so that may have filtered my expression of the issues.  I've version-stamped this: 2013/11/16, and promi…

Social Web Architect
http://bblfish.net/

---

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

Henry,

I’m sure that’s interesting work, but it’s off-topic for this list. 

Thanks,