Re: The CIA mentions us

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 09 March 2017 21:11 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 AB67C1294A3 for <ietf@ietfa.amsl.com>; Thu, 9 Mar 2017 13:11:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.368
X-Spam-Level:
X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 jXwDLjR-QCkv for <ietf@ietfa.amsl.com>; Thu, 9 Mar 2017 13:11:34 -0800 (PST)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 E679B12943D for <ietf@ietf.org>; Thu, 9 Mar 2017 13:11:33 -0800 (PST)
Received: by mail-yw0-x22c.google.com with SMTP id v198so13571432ywc.2 for <ietf@ietf.org>; Thu, 09 Mar 2017 13:11:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=NneRMIpGvPLvdWvQU5cSonVdmYINWzsF5BoJ2UHxQOM=; b=D0HJYuZgBgkHfP/yy4tmDa44aveWLtmZ3MOG75Tbe8lOIB7Ht3hbnRh0yyAIpmPg/r VvsMSWsobNFd2FrgmZgvfRlNjWqp/ivOxdOEaJKERmrjKsGYTtSy4Jg+Uv+FiwLq4pgy DLEovyIJtH302nhyPx+G2g1mr5Radbpf6v+oR5t4NUSxglkmRqv9hW+eZhIMmAJNwrq5 5BfdimR61IOGVxuFl5Sv169UPziyvLgVi5TTIdpi/CqJL3A2nCFuFsUlIAcCCjY14u40 CKSKiObUw5IuFHzlTq/Yh5DPhGCJ/6r9jbVERh3kewXZKa3bmtvK4uiKOgarBLj5KFVL uVTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=NneRMIpGvPLvdWvQU5cSonVdmYINWzsF5BoJ2UHxQOM=; b=l9XmcoZHECzKzRQKCtP2xIrjL3oFr8opliT1776Mf51TBXlVgwJhmVvGmtC7EUzCrW v0p1rh73akl8f4NqnuaX66ZwZc9NflNL8iB0P7bRJVgfjewY2IRZlwTZRT1LEEG4+H6O ZY0MBymznFIl17M8XPxdZ5q1lOC3vMGA97VdRYL5O1N9EGzQDpOxc74cfe0qahnMq1fd WmcIb17x81Ets3vs0dxWV5DlEmURGDEpFwiGCkflQEVJ0XfN6oH/oWVlsp9nD2zCrHlD ISX0R66mgrDTkNDXIAOiYoz8wFReC53QIdqBpB76BB0KpNrYA6W5HxOKeWv2gjx1My4k cu1w==
X-Gm-Message-State: AMke39mk8M5mAVxCnAb6nrwxQw1rH0BwRqRQxAmV3Hy/MGpTZjeAQFjsBFFRph7n+K5mJrGQT1yZEIXQBup65Q==
X-Received: by 10.129.172.25 with SMTP id k25mr5303311ywh.165.1489093892999; Thu, 09 Mar 2017 13:11:32 -0800 (PST)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.83.19.20 with HTTP; Thu, 9 Mar 2017 13:11:32 -0800 (PST)
In-Reply-To: <00A55B3A256BD71DFB1866B4@PSB>
References: <20170307155346.fwhhpnsm4wl6zzoo@nic.fr> <CAMm+Lwh5E-NPXsVWQpK2tA8Rr+6SpvJJKxMbiks7_F1umxz2FQ@mail.gmail.com> <20170307160840.duv7wwg5sm23nrek@nic.fr> <44d06f90-0f38-f6de-8eb1-cf8262369cd5@bogus.com> <c6df6333-1a08-aa0c-c1de-55d335234f2a@si6networks.com> <alpine.LRH.2.01.1703071034050.3764@egate.xpasc.com> <CAMm+LwioHOJxDZudH8Ya9SYv5DT1fPMJ5ypDR8O5JGa4HwxPvg@mail.gmail.com> <F950C538-05E4-451B-8AC0-A42010DAA8D6@piuha.net> <00A55B3A256BD71DFB1866B4@PSB>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Thu, 9 Mar 2017 16:11:32 -0500
X-Google-Sender-Auth: ApLtdDjJaJpMP-JjpouLGaOQT7s
Message-ID: <CAMm+Lwg1MzDOn9xQ_-3oKcZ1odFF552sPGJhu17KRTP0SNR2vw@mail.gmail.com>
Subject: Re: The CIA mentions us
To: John C Klensin <john-ietf@jck.com>
Content-Type: multipart/alternative; boundary=94eb2c1badfc8791ee054a52b043
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/QjCExhwWqaE-e9VNfl6RrAGOswo>
Cc: IETF Discussion Mailing 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: Thu, 09 Mar 2017 21:11:35 -0000

There are two issues

1) Requirements, how should this data be secured?
2) Technology, how can the requirements be met?

I totally agree that transport layer encryption is not enough here. The
security requirement is end to end.

Proprietary products that meet that requirement do exist and the US
agencies that do this work have the financial and technical means to deploy
and use them and I have no problem with the idea of imposing a requirement
on that group that requires them to pay for the tools.

However, it is not just the US agencies doing this work. There are now 117
cyber commands and there is a real problem of 'loose cyber-weapons'. It is
to the interest of the US and to all the other cyber-commands that a norm
is established that cyber weapons are secured end to end throughout their
lifecyle and tools produced to enable that to be achieved.


Such tools do not currently exist. However some key patent expiries that
have occurred and will be complete in November this year make true end to
end data level encryption practical. I have proof of concept but short of
infringing code running in the lab which I will push out as soon as I can
together with the supporting specifications.






On Thu, Mar 9, 2017 at 4:02 PM, John C Klensin <john-ietf@jck.com> wrote:

> Jari,
>
> Let me suggest one addition to your list (with which I otherwise
> agree):
>
> 5. No matter how strong the in-transit encryption or other
> measures, they doesn't mean much if the relevant endpoint hosts,
> or intermediate hosts that have the traffic in the clear, can be
> compromised.  We all know that, but we seem to sometimes need
> reminding.   In particular, while it is definitely not an
> argument against link encryption, we need to be cautious that we
> are not protecting things in a way that inadvertently shifts the
> points of vunerability from one place to another (especially
> another that is either more easily compromised or that
> constitutes larger and more concentrated single point of
> failure) and then assume that it makes things more secure
> overall.
>
> best,
>     john
>
>
> --On Thursday, March 9, 2017 22:36 +0200 Jari Arkko
> <jari.arkko@piuha.net> wrote:
>
> > Up-leveling a bit from the discussion of best practices for
> > surveillance organisations and virus builders (who apparently
> > are partly the same crowd). We can make some more general
> > observations, I think, maybe a bit more relevant for the rest
> > of us.
> >
> > I don't think the reported findings are particularly
> > surprising. But they seem to support what I think we knew
> > already:
> >
> > 1. Security isn't a single feature, but needs to be thought
> > in terms of the whole. Comms security and devices and ...
> >
> > 2. There is no such thing as privileged access to the good
> > guys. It will leak / break / be shared.
> >
> > 3. Secretly held vulnerabilities make us all less safe.
> >
> > 4. The security of our communications and applications matters
> > a lot. Lives are at stake, not just your browsing history.
> >
> > Jari
> >
>
>
>
>
>