Re: IESG meeting thoughts

Phillip Hallam-Baker <phill@hallambaker.com> Tue, 17 May 2016 13:44 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 2D76412D152; Tue, 17 May 2016 06:44:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 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, NORMAL_HTTP_TO_IP=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 fKrI_ixifLK3; Tue, 17 May 2016 06:44:23 -0700 (PDT)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 9A99012D131; Tue, 17 May 2016 06:44:23 -0700 (PDT)
Received: by mail-qk0-x22f.google.com with SMTP id n62so7500743qkc.2; Tue, 17 May 2016 06:44:23 -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=nKTzXrAjF72QcYCloFpvGjK7FcYjmfwPZfN6HKwNhWk=; b=rMhdPBICNQsKC96VtBFkV/2zeZuw5DMTRdlj2dZxPMLQJinYW7VaU+U9grOfnYvv2w b/RMScyIfixczgVH4RHKdLOh6aTByUfV8jC0G68sxompxzvaFLj0Cu+Qf+j9nZxR7dvP CHtfIRMGjDKw/uBUrgVH8F0os8psb7QKUSl5IuXvQ1NB47yjWTxW6u4h2LqV9rCRqarQ YOLsxbqnqw3ruf4N5lHYdHuD8c+vnHw8gy56a4oPikRBFVnQ5rrbor22BcyJ7Z49qQ51 ZkAu/z8VDiMZEsoUmrbp334dwlo8bRZlIFB5K5RYIik5SFMoAELXn1XS7wN4gDfvJm4V j+yw==
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=nKTzXrAjF72QcYCloFpvGjK7FcYjmfwPZfN6HKwNhWk=; b=btC1aN5mZJSOgFR4mMEV1GiV0QykfQiLBn28DEvT3JXKQFRQ561f19veAj3siXf8/Z cADXSzpwDdlo6dFrz8ck94+vJYlIsI1uPM1AyESAiP33ifAgy9B7u0fY4XhJ8ylR+s15 5Ti2X1SW+6Cy446A/Tj3lqIfer0OWX0mfHtOcEa5HQnom78MwOOQ8IEOYUXawPXB2t9/ H0JYg3viOePEGNyRy1cL2WU87GWFJeSBbXtlntnBOGGTnjxZP1Ac9rexr+GGIW1sh4QY H8rhD/UwAlEf2KcH/Ly5xgDzZGULqQY5nipPdSiyTBIk8gUCe8RHVEHJk6iJgqLjLqtW XABQ==
X-Gm-Message-State: AOPr4FVvBxnaQHMvlaggLzL6s6wk4YkBckRMCnE4tCe06WUS7Wv3nAKlEsL0NCATJepeDAq0+jR2F73RBVIuUQ==
MIME-Version: 1.0
X-Received: by 10.55.71.76 with SMTP id u73mr1534176qka.6.1463492662741; Tue, 17 May 2016 06:44:22 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.55.25.105 with HTTP; Tue, 17 May 2016 06:44:22 -0700 (PDT)
In-Reply-To: <573AEAFA.3000905@cs.tcd.ie>
References: <1F81DAB9-AEE8-4250-B10D-C50E2FA66C3E@ietf.org> <573AE765.4010807@bwijnen.net> <573AEAFA.3000905@cs.tcd.ie>
Date: Tue, 17 May 2016 09:44:22 -0400
X-Google-Sender-Auth: DXQu_ZIusy8GRbuZ9v8RDYH5nPw
Message-ID: <CAMm+LwhqUyncTmcAvSRKdM3Eqo3YqSA5enasrVOMJtd--6HOgA@mail.gmail.com>
Subject: Re: IESG meeting thoughts
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: multipart/alternative; boundary=001a114a80124b6f8a053309f03a
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/NU-QgFGkM_9IiqG5Ato4CLQVGaQ>
Cc: IETF Chair <chair@ietf.org>, "Bert Wijnen \(IETF\)" <bertietf@bwijnen.net>, "ietf@ietf.org list" <ietf@ietf.org>
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 13:44:26 -0000

On Tue, May 17, 2016 at 5:57 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
wrote:

>
> Hi Bert,
>
> On 17/05/16 10:41, Bert Wijnen (IETF) wrote:
> > Jari, would you have some more info (maybe popinters) about
> >
> >     The IESG also got an update on “Cryptowars” situation from Jeff
> > Schiller.
> >
> > When I look up "cryptowars" on google, I get many many hits on a wide
> > variety of "cryptowars". So I'd like to know which specific ones
> > were discussed or cause us specific worries.
>
> No pointers to the talk, sorry - Jeff was kind enough to speak without
> notes or slides, (which was great:-). He recounted the 1990's era
> history of crypto export controls, the issues covered in their "keys
> under doormats" report, [1] and some consideration of more recent
> events such as the USG/Apple case and how similar issues might play
> out in future. (My own not at all startling prediction: ongoing
> tensions between law enforcement and all of us working to improve
> security and privacy are sort of inevitable it seems.)
>
> From my POV this was a great way to bring ADs who don't follow
> the minutiae up to speed on these topics, but didn't set out any
> particularly new direction for work in the IETF.
>
> (Thanks go to Jeff for the talk and to Kathleen who organised it.)
>
> Cheers,
> S.
>
> [1] http://115.69.40.134/files/editorials/files/MIT-CSAIL-TR-2015-026.pdf


One thing we did in the 1990s which I now regret as a mistake was that we
ended up developing security protocols where the first priority was to
defeat government intercept rather than meet users needs.

Unlawful intercept is of course a very serious problem but it is not the
only problem our users face nor is it the necessarily the most serious
concern. Nor for that matter is targeted unlawful intercept the same
problem as mass surveillance.

One consequence of treating Louis Freeh's FBI as the principal threat was
that we ended up with a lot of security protocols that were perfectly
secure but almost nobody deployed and even fewer used. end to end security
is only good security when people use it.

Right now I am working on technology that makes end-to-end security
practical and usable. 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.

Another mistake we made was to consider end to end security to be the
be-all and end-all of security. I like end to end security. The Mesh is
designed as an untrusted cloud precisely because I consider end-to-end
security important. The Mesh cannot be breached because none of the data
stored in the Mesh is confidential. The only places confidential data is
not encrypted is at the endpoints.

But end to end security has serious costs. You can't have end to end
security without a key infrastructure. And until the Mesh there hasn't
really been a key infrastructure that was designed for use by non-expert
users. And end to end security isn't the 'best' security, it is only one
form of security. End to end doesn't provide protection against metadata or
traffic analysis. The Mesh has end-to-end and transport layer security. The
most critical operations even have a third layer of encryption. And I can
give a security rationale for each.

Another critical security technology that we managed to allow ourselves to
be persuaded was 'evil' is trustworthy computing. As a result the WebPKI
and code signing infrastructures use private keys that are stored on the
machine itself, in many cases in plaintext but with security through
obscurity at best. But we have the technology that would allow us to bind
those private keys to servers in such a way that they can be used but not
extracted without physical access to the machine itself and a significant
degree of technical effort.

So lets make sure we don't make the same mistake this time round. Transport
layer security and key escrow have security liabilities as well as
benefits. Trustworthy computing is a tool that we can and should be using
to make our users secure.


What is popular and commonly agreed in computing isn't always the right
thing. Security is allowing our users to control risk, not defeating the
political objectives of Louis Freeh or the RIAA.