Re: [perpass] A reminder, the Network is the Enemy...

Phillip Hallam-Baker <hallam@gmail.com> Sat, 07 December 2013 00:01 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E1A1AE11D for <perpass@ietfa.amsl.com>; Fri, 6 Dec 2013 16:01:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BS8URem6trmD for <perpass@ietfa.amsl.com>; Fri, 6 Dec 2013 16:01:28 -0800 (PST)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id AC7B61AE0EA for <perpass@ietf.org>; Fri, 6 Dec 2013 16:01:27 -0800 (PST)
Received: by mail-wi0-f175.google.com with SMTP id hi5so1609130wib.14 for <perpass@ietf.org>; Fri, 06 Dec 2013 16:01:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m0rhn2f0G60ik3Aoau6Sooj5fYBGCGRPlPDqGaxN9Jk=; b=0OFNW7OvVGxFXxDywVlR+41gSWnDC6TlAODguBNgtlMp+k57zjvzbw33eH1dB9CbHR 3fWU0MpqaFQQjM+0HbOD2/iceQgvH9yBbACr/ba9wVEAEynIUCoso+K9ZukeyAZNIOUu RfOw0yNBwdN3gqmXkGPJh7QkoYKEp1OIVDg57cnlMdSAdu9GSRlwts5KCKFAGvxOug61 Bj0MgIFP0dsxEb4LJ3papQtK+Oa8hNE7x+7A2h+k+TpLka4Y2UxDJjNpJFIcrlqdwxJb FEsHauTNor21ZbmMHY6QcRFenS9U9EBXsUd8e4OQfMb5lQloZzKQzW4AH3H2NTOjtZiO W2cw==
MIME-Version: 1.0
X-Received: by 10.180.108.97 with SMTP id hj1mr4615427wib.59.1386374483390; Fri, 06 Dec 2013 16:01:23 -0800 (PST)
Received: by 10.194.243.136 with HTTP; Fri, 6 Dec 2013 16:01:23 -0800 (PST)
In-Reply-To: <30BA9CB8-129F-4D9A-AF5F-EB6309A4F15A@virtualized.org>
References: <C0D19C51-6EA6-4EAF-B9CB-D80F673262E5@icsi.berkeley.edu> <52A050E7.8010405@uni-due.de> <m2y53z1g2r.wl%randy@psg.com> <CAMm+LwgJU9DSyrOCi0h7WfV4m4ULAAXqnQt9=PUaonTtvU5mzw@mail.gmail.com> <30BA9CB8-129F-4D9A-AF5F-EB6309A4F15A@virtualized.org>
Date: Fri, 6 Dec 2013 19:01:23 -0500
Message-ID: <CAMm+LwhByOrxv-BVST5YaHWzPfiZZB2KOYRkpXMBKrtK+P4J0A@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: David Conrad <drc@virtualized.org>
Content-Type: multipart/alternative; boundary=e89a8f3bafef9bb68604ece6762e
Cc: Randy Bush <randy@psg.com>, perpass <perpass@ietf.org>, =?ISO-8859-1?Q?Matth=E4us_Wander?= <matthaeus.wander@uni-due.de>
Subject: Re: [perpass] A reminder, the Network is the Enemy...
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass/>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Dec 2013 00:01:30 -0000

On Fri, Dec 6, 2013 at 11:12 AM, David Conrad <drc@virtualized.org> wrote:

> On Dec 5, 2013, at 7:27 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> > A better approach is to design the system so that it takes a defection
> by more than one party. Instead of relying on just the ICANN root KSK
> require a TLD to be signed by three out of five trusted national cryptolabs.
>
> Trusted by whom? E.g., trusted like NIST now? (No disrespect of folks at
> NIST intended: just observing some may no longer view them as trustable)
>

I mean trusted in the technical sense of relying on them (albeit to a
qualified degree).

And it is important to note that trusted does not mean the same thing as
trustworthy, a point I raised at one of the early trusted computing group
efforts (only Microsoft seemed to take note or maybe they came up with the
understanding independently).

If you have a three out of five scheme one should choose five labs that are
very likely to collude. The UK, US, Australia, Canada and New Zealand would
not be a very good choice. The UK, France, Russia, India and Brazil would
be a rather better one. Of maybe you would want to have the EFF or the like
in there (if they could set up a secure facility and maintain it at
acceptable cost).



> I personally believe a better approach is to make the operation of the
> system extremely public and documented such that it doesn't matter who is
> involved since the risk would be too high that attempts at compromise would
> be observed. This is what ICANN tried to do with the root KSK (one can
> argue whether they succeeded).
>

These do not need to be exclusive, nor was that my proposal. I would expect
any national cryptolab to follow the established industry practices.


-- 
Website: http://hallambaker.com/