Re: Security for various IETF services

Phillip Hallam-Baker <hallam@gmail.com> Thu, 10 April 2014 14:57 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EC61A0224 for <ietf@ietfa.amsl.com>; Thu, 10 Apr 2014 07:57:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level:
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 JtsPK09HcKfp for <ietf@ietfa.amsl.com>; Thu, 10 Apr 2014 07:57:15 -0700 (PDT)
Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 66E4D1A01DC for <ietf@ietf.org>; Thu, 10 Apr 2014 07:57:15 -0700 (PDT)
Received: by mail-lb0-f173.google.com with SMTP id p9so2387385lbv.4 for <ietf@ietf.org>; Thu, 10 Apr 2014 07:57:13 -0700 (PDT)
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:content-transfer-encoding; bh=aMlXe5673i3+2xr8u44ju/1x8PZjN0B9UN63dS7hTlo=; b=orvu8afYLUoA/xvnb5QIN56p4Fa3bHPTjB9Xnq247zBrs96cLJdPVl+VVpnBy5wkDB hLi2YkRiIiy3P/6t+gxeLmV5Lxs2X/m2ZQuUPo8ReOXAKdMOFbHYWMvQQBfLWursKgRS OcAKbJ00LsJRw8eNA7/8k8uqVYj5+Nq+kvdqXZp++wBli8zk/9bLSv4bjTnoByZmwXuh PhfQTBmrQCR3JWKmRjSN8sAyajEIgTfebyDbN2/dutEIX05uaT9OuSHeqoVIQeqj5vcn lTgQJzBoCxkHDARJ0J9loueFWqaIf2r6wFfoOLAkTE51a4Rwb29/+eL+18Oy5u+5lOan SOUQ==
MIME-Version: 1.0
X-Received: by 10.152.234.229 with SMTP id uh5mr392257lac.64.1397141833683; Thu, 10 Apr 2014 07:57:13 -0700 (PDT)
Received: by 10.112.234.229 with HTTP; Thu, 10 Apr 2014 07:57:13 -0700 (PDT)
In-Reply-To: <3C46B827-BFFC-4A9E-B600-A1E79C839970@shinkuro.com>
References: <20140409154919.11E6118C106@mercury.lcs.mit.edu> <534580AF.4080602@dcrocker.net> <20140409200814.GA15303@thunk.org> <3C46B827-BFFC-4A9E-B600-A1E79C839970@shinkuro.com>
Date: Thu, 10 Apr 2014 10:57:13 -0400
Message-ID: <CAMm+Lwj0bUZEwBJ+PW4GW_EYJtQKhxsGzGuFLcrVQQbATQCe6A@mail.gmail.com>
Subject: Re: Security for various IETF services
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Steve Crocker <steve@shinkuro.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/2o6e6yGlJOScJlJGwaMMhZWpeKs
Cc: Noel Chiappa <jnc@mercury.lcs.mit.edu>, Theodore Ts'o <tytso@mit.edu>, IETF Discussion Mailing List <ietf@ietf.org>, David Crocker <dcrocker@bbiw.net>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 10 Apr 2014 14:57:20 -0000

On Wed, Apr 9, 2014 at 4:15 PM, Steve Crocker <steve@shinkuro.com> wrote:
> My own opinion is related but not identical.  I agree solutions 1 and 3 are failures; 1 doesn’t provide the trust and 3 doesn’t scale.  Solution 2 is also problematic because the government tends to overreach and there isn’t a single government.
>
> DNSSEC provides a base platform to build upon.  It doesn’t claim to provide the level of trust the CA system tried to provide.  That’s a key strength, not a weakness.
>

I agree as long as you continue to use the indefinite article. DNSSEC
is A platform to build on, so is PGP and so is S/MIME. There is
actually a considerable built out base of S/MIME that is just as large
as PGP and in fact gets a lot more use.

On Monday I was in a room where over half the audience put their hand
up when I asked it they had used encrypted mail that week.


The way forward as I see it is to separate out the trust model
question from the steps necessary to support encryption in the client.
At the very least for development purposes. My prototype is designed
to allow anyone to plug their favorite trust model in as a web
service. So we can share 95% of the code that is the hardest to write
and has to be supported on every platform. We only need to implement
the 5% where the difference lies.


Given this week's Heartbleed news, I think we can stop hearing
conclusions drawn from DigiNotar. No crypto is ever going to be
perfect, get over it. If people want to hold CAs up to a 'zero
tolerance' standard, thats fine. Just make sure you hold OpenSSL up to
the same standard and pull them from the code base as well. And kick
anyone who might have been implicated in an NSA plot out of the IETF.
And stop using all their specs. And.. and., and..

The problem with the CA model for email is that as a CA it is really
difficult for me to actually validate individuals. The best I can do
is to check their government issued ID. Which really does not help me
in a country like Iran. The CA model does give me a lot of leverage if
I am looking to authenticate an institution however.

Web of trust has a scaling problem that I illustrate in the video.
Basically a web of trust with 1000 members that is ten hops away from
me has a work factor of essentially zero as I have no way to tell if
it is genuine or fake. But the curious thing is that if we combine the
two models, the work factor for the attacker increases over the CA
model alone and we get scaling. If there are 50 members of that web of
trust with CA validated certificates with a work factor of X, the web
of trust might have an average work factor approaching 20-30X for a
given cert.




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