W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: Protocol Design 101 (Re: Mandatory encryption)

From: Mark Watson <watsonm@netflix.com>
Date: Wed, 18 Jul 2012 16:23:39 +0000
To: Carsten Bormann <cabo@tzi.org>
CC: Tim Bray <tbray@textuality.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-ID: <5567E1B7-BD5B-42E3-886B-45771CB3B18F@netflix.com>
+1

I do encourage people to read the "tussle" paper: http://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle%20in%20Cyberspace%20Defining%20Tomorrows%20Internet%202005's%20Internet.pdf

…Mark

On Jul 18, 2012, at 8:34 AM, Carsten Bormann wrote:

On Jul 18, 2012, at 17:09, Tim Bray wrote:

Privacy is good

Ah, nice, another textbook example for Protocol Design 101 is in the
process of being made.

To the people who want "mandatory encryption" because "privacy is good":

You are designing a mechanism (here: HTTP 2.0).  If you happen to like
a certain policy (here: good privacy) today, you may be tempted to
cripple the mechanism so it only "allows" that policy.

Unless the policy comes with zero cost and is universally accepted,
this sets you up for failure:

1) People who don't like your favorite policy will not use your
  mechanism.  Worse, rational people who know that their potential
  peers might not like the policy will not use your mechanism.  And
  rational people who know that there are the second kind of people
  will not use it either, and so on.
  The transitive closure is empty, but for a few zealots.
2) You may (read: will) find out later that you didn't think of the
  use cases for the mechanism where the policy is useless or actively
  hurts.

If you don't understand how this works, it is nicely documented in
Dave Clark et al.'s famous "tussle" paper.

As a general rule, mechanisms MUST be neutral to the outcome of
tussles.  Design for choice.

(Now there are exceptions to this rules, where a mechanism is actually
being designed for a new applications space that is properly delimited
by the applicability of the policy.  Creating a putative replacement
for a protocol as ubiquitous as HTTP is NOT this case.)

That'll be your lecture for the day :-)
Now the assignment:

What we really should be working on is removing the obstacles we have
today for widely deploying privacy-enhancing mechanisms.  (Hint for
solving this assignment: Designing an NG protocol with "mandatory
encryption" is not helping in this at all.)

Grüße, Carsten
Received on Wednesday, 18 July 2012 16:24:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 18 July 2012 16:24:14 GMT