Re: [saag] Liking Linkability

Ben Laurie <benl@google.com> Wed, 24 October 2012 11:32 UTC

Return-Path: <benl@google.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE16421F8B76 for <saag@ietfa.amsl.com>; Wed, 24 Oct 2012 04:32:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level:
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYqhE9QmbqmK for <saag@ietfa.amsl.com>; Wed, 24 Oct 2012 04:32:08 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7AB21F8A07 for <saag@ietf.org>; Wed, 24 Oct 2012 04:32:07 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id dr13so220282wgb.13 for <saag@ietf.org>; Wed, 24 Oct 2012 04:32:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=hf6aEg3E6+jKXtlhnnu2FFqbNao3DYxs7Zq4CyVpHrg=; b=FW22yfZOXWwLUKd6yVioW3dB1SiaR9tDJZN5ws45S+VgH09cCM711Wl5py5F4satzM Kksuid4ZWKtcA1VFckmq5ZnU6yq5UzTieExR8kR29qUdIt7u2Tc4WitxQ1Xksf+nBMKo mL6/wcpIBQWzDbGcV1D332VQriX1ytzKcppwPIuwudyF8JM51fxigw9Mm4KwT3o94VIa jtueUdj6iOXvhZqyAB1pY59dLgJg1ujwXTR/J1OOwbJy1dgHBzpvPlsz4z6lx8SBmDOI DO8oJXZJZTE2hjD192m9kPzNPJBE0FCJ0nyJoyC7uCsaZFYZFaDH92ndccTAfepO+ePX OgKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=hf6aEg3E6+jKXtlhnnu2FFqbNao3DYxs7Zq4CyVpHrg=; b=ElPn976hgtnHqpb7QZZtyyw+abKXYRYlHyPWC5UxgZlMPA6ki/p0NNqZTnqmnUV9hs OXtB/9VRR0P1SoFfeSPHCk+L4JuN8X7dxuyOsPP29WjDkd9dzbskcdxUzFzABHduN2Tq S4plHthZxAE8z7b+wX2cn5aqY0D4p3Jd70hUDnltplTQqru3pQUt0HJ8t8mKhE/ekL9i IQ7rGRz2IPG4+0q1GFd3diTyXWWMWLGSwZ6QJDDUW8hP6atrCNT8aULPdz05yk2Lrz4v XahF3JgV0UsKpI7eRd0vi98EfnWfoguDbCmlwdPFb0rzaDXLyyr57frsLJkyfcOGmWWs wFNQ==
MIME-Version: 1.0
Received: by 10.180.100.101 with SMTP id ex5mr1797098wib.16.1351078326792; Wed, 24 Oct 2012 04:32:06 -0700 (PDT)
Received: by 10.194.76.170 with HTTP; Wed, 24 Oct 2012 04:32:06 -0700 (PDT)
In-Reply-To: <E8AC244A-1D90-49F2-BD8A-2CF13E11D4B7@isoc.org>
References: <CCA5E789.2083A%Josh.Howlett@ja.net> <tslzk3jsjv8.fsf@mit.edu> <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <FB9E461D-CA62-4806-9599-054DF24C3FD9@bblfish.net> <CAG5KPzxGz+4MywjP4knfbDr2gyvqUZc1HEBXgtaDfYT+DPg5yg@mail.gmail.com> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <CABrd9SQghpi6_rVQKxYXZDtM5HwvE7Kq7SUw5zi41ZRd3y2h9A@mail.gmail.com> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <CABrd9SQU1uYVaVPedokHxeYkT=759rkPFfimWK1Z8ATzo3yNFA@mail.gmail.com> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> <CABrd9SRNVLbWxifQAQ6iuX4qMeFmZVD6rO_q=L348G1UZzr9tg@mail.gmail.com> <50852726.9030102@openlinksw.com> <CABrd9SQ3KTqHq1hOfbLAU5hfgNyqCPK4u+ToEda+VtQ5S0utwA@mail.gmail.com> <5085360E.3080008@openlinksw.com> <50853CD8.8020005@w3.org> <5FB468E4-BDD3-4635-ACD0-A23540C08751@bblfish.net> <508562C2.1060905@w3.org> <3EF3A430-A6C5-4ADE-92B5-0744DFFD326B@isoc.org> <CABrd9SQxy3GjKekrrCPikqRBt4z2PdzbOhzZUsDC6asZNSiu0A@mail.gmail.com> <E8AC244A-1D90-49F2-BD8A-2CF13E11D4B7@isoc.org>
Date: Wed, 24 Oct 2012 12:32:06 +0100
Message-ID: <CABrd9STgiLqthDPqYtRsKSPg7SJrg+DNwMCMF37tFHCAV98c+w@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Robin Wilton <wilton@isoc.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmIxgkikbbKu3eUg0zBSwwaCl0/U5eut67q8drqtbhwR3JKp1TM09vWjA+NL4KhZVM3B4+oczlCUJDKXNJ0utWPdrqs4kDwwHN5X8aGiaZNsxuGuwClvMBP2twqDsb4TZ4L0p0m1/fLwUNfRKiEM11TnVTFc1ZYc6LrWxr9sxfQuKzBKYvvVJmK1vMW//InjZ+PL/jS
Cc: Halpin Harry <H.halplin@ed.ac.uk>, public-identity@w3.org, saag@ietf.org, "public-privacy@w3.org list" <public-privacy@w3.org>, public-webid@w3.org
Subject: Re: [saag] Liking Linkability
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Oct 2012 11:32:08 -0000

On 24 October 2012 12:26, Robin Wilton <wilton@isoc.org> wrote:
>
>
>
>
>
>
> Robin Wilton
> Technical Outreach Director - Identity and Privacy
> Internet Society
>
> email: wilton@isoc.org
> Phone: +44 705 005 2931
> Twitter: @futureidentity
>
>
>
>
> On 24 Oct 2012, at 10:30, Ben Laurie wrote:
>
> On 23 October 2012 10:58, Robin Wilton <wilton@isoc.org> wrote:
>
>
>
> On 23 Oct 2012, at 09:44, Ben Laurie wrote:
>
>
> <snip>
>
>
>
> Not disagreeing with any of the above, but observing that:
>
>
> a) There's no particular reason you could not have an email per site
>
> as well as a key per site.
>
>
> b) Linkability it not, as you say, inherently bad. The problem occurs
>
> when you have (effectively) no choice about linkability.
>
>
>
>
> But it's very hard to use either of those mechanisms (separation through
>
> emails or keys) without giving some third party the ability to achieve total
>
> linkability. (In other words, both options remove effective choice).
>
>
> I agree that emails are a problem, but not at all sure why keys are?
> In the case of appropriate selective disclosure mechanisms, even if
> there were a third party involved, they would not be able to link uses
> of the keys. Also, if you insist on using linkable keys, then per-site
> keys do not involve third parties.
>
>
> It may just be that I'm not getting a clear mental picture of your
> architecture. But here was my thinking:
>
> - If you use symmetric keys, you get a system which can't scale unless you
> opt for Schneier's idea of a key server… but then the key server becomes a
> point of potential panopticality.

Symmetric keys obviously don't work.

> - If you use PKI, *and* you want your communicating parties to be able to
> validate the certs they're relying on, then you have to design a CRL- or
> OCSP-like mechanism into the architecture, and again you end up with a
> component which is potentially panoptical. (Plus, you have to address the
> 20-year-old problem of how to make PKI usable by human beings, when recent
> history suggests that PKI only takes off where human beings are kept well
> away from it).

Per-site keys don't really need the I in PKI, just the PK. Revocation
need not be centralised - I am not saying it is trivial, but it is
akin to the problem of forgotten or compromised passwords.

Also, it is possible to blacklist using selective disclosure - i.e.
detect whether a key has been revoked without revealing the key.