Re: [therightkey] Basically, it's about keeping the CAs honest

Nico Williams <nico@cryptonector.com> Tue, 14 February 2012 19:18 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: therightkey@ietfa.amsl.com
Delivered-To: therightkey@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B8F21E801B for <therightkey@ietfa.amsl.com>; Tue, 14 Feb 2012 11:18:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.858
X-Spam-Level:
X-Spam-Status: No, score=-1.858 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSkU091tXJj6 for <therightkey@ietfa.amsl.com>; Tue, 14 Feb 2012 11:18:27 -0800 (PST)
Received: from homiemail-a87.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 378E621F879E for <therightkey@ietf.org>; Tue, 14 Feb 2012 11:18:27 -0800 (PST)
Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id CB50726C073 for <therightkey@ietf.org>; Tue, 14 Feb 2012 11:18:26 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=x0ffGd9O1bbwIk5xTWxVdAEoDDqSHCLsNdr70TKuzBfG iz+1XXz7IJxa8b7EZn+5Ks2n3Hw7l9s2qtejQxPDLr+9/oCVAAEASbs5RmiaiBi5 /3O8ZNmYIGxtwroHJLoG0T0pkHIIV28szEov+WUWwGBt6sYj419NX8nIirO9mVc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=l+zWSzUxdEpRIiCR1PsPhOok4Gw=; b=YDUj0671PuY dG6GRIaON1Sq0GwARsEWWuVJWUJYp8HCxp50CyLRYMbXeF/6La2O0OUClI8ASj7q l6HXA0LFtdmsGup6MT5yTJ9EXw8o+DBtNyZ4NMg9CqARqaF5jPvw/1pP7u8Va9AI 5HedwgOq7TRmB41s673foNhoPw/OF4xk=
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id B92A826C00C for <therightkey@ietf.org>; Tue, 14 Feb 2012 11:18:26 -0800 (PST)
Received: by dakl33 with SMTP id l33so245373dak.31 for <therightkey@ietf.org>; Tue, 14 Feb 2012 11:18:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.233.231 with SMTP id tz7mr3273516pbc.91.1329247106334; Tue, 14 Feb 2012 11:18:26 -0800 (PST)
Received: by 10.68.136.4 with HTTP; Tue, 14 Feb 2012 11:18:26 -0800 (PST)
In-Reply-To: <CAMm+Lwi=ekew5_Sp0UTcS9h4KBCPA6TADOeXD=wL3=-FNbLoEg@mail.gmail.com>
References: <CAK3OfOhx_xbx1TrJL==BjmqVM8zZKDa8u4rQ7wCpKom4ZZODOg@mail.gmail.com> <gym47alhbg7shuun2mjezwJv4X.penango@mail.gmail.com> <CAK3OfOiiT6bssAsN3ot8MUiwhQKndMxtU-_f5bvrUSLjE55x9Q@mail.gmail.com> <CAMm+Lwi=ekew5_Sp0UTcS9h4KBCPA6TADOeXD=wL3=-FNbLoEg@mail.gmail.com>
Date: Tue, 14 Feb 2012 13:18:26 -0600
Message-ID: <CAK3OfOhDDzubcbg-CfyViN4CyGrs0Q6468JRaTCjiUttkadMtQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: therightkey@ietf.org, mrex@sap.com, Kyle Hamilton <aerowolf@gmail.com>
Subject: Re: [therightkey] Basically, it's about keeping the CAs honest
X-BeenThere: therightkey@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <therightkey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/therightkey>, <mailto:therightkey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/therightkey>
List-Post: <mailto:therightkey@ietf.org>
List-Help: <mailto:therightkey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/therightkey>, <mailto:therightkey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Feb 2012 19:18:28 -0000

On Mon, Feb 13, 2012 at 7:00 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> Before quoting end to end I strongly suggest that you actually read
> the Clark paper because it probably does not say what you think it
> does. The argument is actually about complexity and strategies for
> addressing it.
>
> The end-to-end security model is bunk when it comes to PKI because the

The end-to-end model is broken whenever authentication is mediated by
third parties that can MITM you or worse.  This applies to PKI and
Kerberos, for example.

But the end-to-end model isn't entirely broken as a result.

There's a pretty decent analogy to be made between off-line human
behavior and on-line security protocols as far as trust establishment
goes.  Namely: we depend on repeatability of results for judging
trustworthiness (and much else besides), and in the absence of long
shared history with our peers we do tend to depend on transitivity for
trust to bootstrap new pair-wise trusts.  There are lots of times in
the off-line world when impersonation can occur, but we act as though
the risk of compromise goes down as we repeat experiences.  Even
beyond impersonation, trust between individuals grows over time as
they show each other that they are trustworthy.  But what is the
on-line equivalent of this?  I'd say that something roughly along the
lines of cert pinning is one equivalent: "gee, servers with this cert
haven't stolen all my money yet, and it's been three years, so, yeah,
I trust this cert".  <hand-waving topic="rollover issues"/>

Grant me this analogy for the sake of this argument.

We can use trusted third parties to bootstrap pair-wise trusts and use
those pair-wise trusts to get end-to-end security, meaning, really:
establish pair-wise secret session keys that others don't get to
discover, including the trusted third parties unless they're willing
to MITM or collude with the peer for a very long time.  If a trusted
third party has to be an MITM for years to avoid discovery, they won't
be an MITM at all because that's just too difficult to pull off
(unless the users are an extremely captive audience).

In other words: I'm arguing that while it's true that trusted third
parties weaken the end-to-end security model, they don't fundamentally
prevent the end-to-end model from being faithfully applied, they just
add considerations, caveats, difficulties, but not insurmountable
ones.

> end points of every communication are either people or corporations
> and neither can do big number modular arithmetic without some form of
> computer support.
>
> So there will always be at least three hops in your model:
>
> Alice <-> Computer  <-> Computer <-> Bob

Sure.  We make some simplifying assumptions because humans are
insufficiently fast computers.  Our devices speak for us, else we'd
not need those devices in the first place.

> This really matters a heck of a lot when you start to consider real
> world issues like usability.

Definitely.

Nico
--