Re: IESG meeting thoughts

Phillip Hallam-Baker <phill@hallambaker.com> Tue, 17 May 2016 17:10 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1192712D730; Tue, 17 May 2016 10:10:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 G1qyWSsFAa8U; Tue, 17 May 2016 10:10:56 -0700 (PDT)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ECEC12D70C; Tue, 17 May 2016 10:10:55 -0700 (PDT)
Received: by mail-qk0-x229.google.com with SMTP id n62so11023507qkc.2; Tue, 17 May 2016 10:10:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=K/22DSSP+OXpkG3ceLqmPghSByOuOtM8NFvkhwaCmfw=; b=KeJ9l9aVTsj+oX0kCRVXhrCKio5xdJNsgIER3pe88YS4B3W9KXLOSIdAmVCVBC5GSj UHTGzkI/cw6Uc2x21CzBu9odRbTckKAQrwthCA7ZrWLptt3Uvq8p2hyrFII62jKI3WR8 rMJywdeYjKX8JP7Dvkv8GsUgFmU/ExY4EvEkl2D8TDJ4StxuSen/QCwSwqVX7fpOlE2q x9PbgR0lJzpUPvdDDGG0Ycl/FwL4LnEXPZKxT6840Cz5sBolOHAeOxi2xQstyKP652ta L4AN1o65q5efoDOmZ+d4Uatg4PvRtK9iP+iPJSXLiZo2Ag3Xcn1CB+5VXBHYyL8CKd6l eInQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=K/22DSSP+OXpkG3ceLqmPghSByOuOtM8NFvkhwaCmfw=; b=D/3TilkskkEv4wTyYJ0d/n9rMh2y3gxs2QNzVMLNgsfutwCEv8XT6s51i1d1kFcnEX /eg3C4Q10k6rybx3Q0ruYrX6UxDp9SQ3/RAOwp1HVOai1hO+Z3sAJs2sh7oOzI1ra7Nj 8P6lwDLYOBeDFJGu+X+Lv1ShL5CUOgsHuFiWBu0GYOE9z0kHlH5AwC9kT/fHhmbWXsNT np67e0OAoh38+w+ju3pQYzlSaf4jdpsD9g5qfpZb+o/7T4juU+5B/4vmqotorTCeOJSb U0LSL4l3GGVnTwGSuEjaB23wkADlrgwaFVdjC29ljGL5vWY4evhUWOIc1H9yJufTgufG 4jaw==
X-Gm-Message-State: AOPr4FX0KBMhSwzuJu6w13N8wNbkuJiMbtjcWAd4nUowUnmo5j4cMAde7yPLz21rqXKRyNf9S/xpvXNFdiTmtA==
MIME-Version: 1.0
X-Received: by 10.55.192.71 with SMTP id o68mr2897850qki.27.1463505054785; Tue, 17 May 2016 10:10:54 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.55.25.105 with HTTP; Tue, 17 May 2016 10:10:54 -0700 (PDT)
In-Reply-To: <29077.1463504337@obiwan.sandelman.ca>
References: <1F81DAB9-AEE8-4250-B10D-C50E2FA66C3E@ietf.org> <573AE765.4010807@bwijnen.net> <573AEAFA.3000905@cs.tcd.ie> <CAMm+LwhqUyncTmcAvSRKdM3Eqo3YqSA5enasrVOMJtd--6HOgA@mail.gmail.com> <29077.1463504337@obiwan.sandelman.ca>
Date: Tue, 17 May 2016 13:10:54 -0400
X-Google-Sender-Auth: yzuVC4HgET79Op1CkD3G7JUS0tg
Message-ID: <CAMm+LwiN58YtdDJ8KjhMOYo_oua2Am0b0EoKsfUkvdS9a_jLVQ@mail.gmail.com>
Subject: Re: IESG meeting thoughts
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Content-Type: multipart/alternative; boundary="001a1149dbdaeae9e805330cd28e"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/-kztU8F_4Fzyuc6W0wgTgNlWP10>
Cc: IETF Chair <chair@ietf.org>, "ietf@ietf.org list" <ietf@ietf.org>, "Bert Wijnen (IETF)" <bertietf@bwijnen.net>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 May 2016 17:10:58 -0000

On Tue, May 17, 2016 at 12:58 PM, Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> Phillip Hallam-Baker <phill@hallambaker.com> wrote:
>     > Right now I am working on technology that makes end-to-end security
> practical
>     > and usable.
>
> This is awesome; I'm hoping that microsoft, apple and google will pay
> attention and collaborate.  In the 1990s, I think that one reason we wound
> up
> where we did was because the work was being done by academics and later by
> dot-com startups.  Who has the resources to collaborate with you?


Right now the problem seems to be that everyone wants to play to be the
only king of the castle like they did with instant messaging when it was
the hot thing.

A personal PKI isn't going to give people personal autonomy and freedom if
it binds them to only one provider with purposefully high switching costs.
Nor is it going to have an effective network effect if you can only
communicate with people in the same network as you.


I am busy working on reference code and specs. I should have a significant
system to show in Berlin. It is all open source, MIT license and on GitHub,




>     > Using off the shelf mail applications with the Mathematical Mesh
>     > is actually easier than using them without. But there are some
> features I
>     > have added to meet real end user needs that we would never have
> considered in
>     > the 1990s. In particular a key backup and recovery option that is
> turned on
>     > by default.
>
>     > Why do real users need key recovery? Well without the ability to
> recover a
>     > lost key, a protocol that encrypts stored data becomes worse than
> ransomware.
>     > There isn't even the option of paying a criminal to get your data
> back.
>
> That's very true.
> I have been wondering, in the context of Apple's improvement to device
> security, how the untimely death of a person will be dealt with.


These are serious problems that have to be planned for. Right now I have
code to do Shamir keysharing to escrow the long term escrow keys. But if
people want to use this as a life long personal security infrastructure,
they need to be able to identify some papers as being so personal that they
die with them and others that become public on their death. For example
where I buried Aunt Agatha's jewelry is something I want to make public.
Where I buried Aunt Agatha, is not.



>     > Another critical security technology that we managed to allow
> ourselves to be
>     > persuaded was 'evil' is trustworthy computing. As a result the WebPKI
>
> It wasn't trustworthy, because they refused peer review.
> We couldn't even get Intel to reveal pre-whitened random numbers!
> (correct me they ever fixed that...)


Well, see my recent work on multi-party key generation. When we make the
move to DH based crypto puzzles with Elliptic Curve and beyond, I have
schemes that allow you to make use of the security hardening properties of
onboard crypto without revealing all of the private key to that system.