Protocol Design 101 (Re: Mandatory encryption)

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 15:34:53 UTC