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/
- Security for various IETF services Stephen Farrell
- RE: Security for various IETF services l.wood
- RE: Security for various IETF services Randall Gellens
- Re: Security for various IETF services Fred Baker (fred)
- RE: Security for various IETF services ned+ietf
- Re: Security for various IETF services Dave Crocker
- Re: Security for various IETF services Randall Gellens
- Re: Security for various IETF services Pranesh Prakash
- Re: Security for various IETF services Fred Baker (fred)
- Re: Security for various IETF services Douglas Otis
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services Fred Baker (fred)
- Re: Security for various IETF services Brian E Carpenter
- Re: Security for various IETF services Randy Bush
- Re: Security for various IETF services Scott Brim
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services ned+ietf
- Re: Security for various IETF services Dave Crocker
- Re: Security for various IETF services Randy Bush
- Re: Security for various IETF services Randall Gellens
- Re: Security for various IETF services Martin Rex
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services t.p.
- Re: Security for various IETF services John C Klensin
- Re: Security for various IETF services Ted Lemon
- Re: Security for various IETF services John C Klensin
- Re: Security for various IETF services Dick Franks
- Re: Security for various IETF services Hector Santos
- Re: Security for various IETF services Dick Franks
- Re: Security for various IETF services Hector Santos
- Re: Security for various IETF services Dick Franks
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services Pranesh Prakash
- Re: Security for various IETF services Martin Thomson
- Re: Security for various IETF services John C Klensin
- Re: Security for various IETF services Stewart Bryant (stbryant)
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services Hector Santos
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services ned+ietf
- Re: Security for various IETF services Tim Bray
- Re: Security for various IETF services Stephen Farrell
- Re: Security for various IETF services Dick Franks
- Re: Security for various IETF services Stephen Farrell
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services David Morris
- RE: Security for various IETF services Christian Huitema
- RE: Security for various IETF services l.wood
- Re[2]: Security for various IETF services mohammed serrhini
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services Randy Bush
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services S Moonesamy
- Re: Security for various IETF services Stewart Bryant
- Re: Security for various IETF services Stewart Bryant
- Re: Security for various IETF services Brian Trammell
- Re: Security for various IETF services Stewart Bryant
- Re: Security for various IETF services Stewart Bryant
- Re: Security for various IETF services Stewart Bryant
- Re: Security for various IETF services Stephen Farrell
- Re: Security for various IETF services Ted Lemon
- Re: Security for various IETF services John C Klensin
- Re: Security for various IETF services Spencer Dawkins
- Re: Security for various IETF services Stewart Bryant
- Re: Security for various IETF services Ted Lemon
- RE: Security for various IETF services l.wood
- RE: Security for various IETF services Matthew Kaufman (SKYPE)
- RE: Security for various IETF services Eric Gray
- Re: Security for various IETF services t.p.
- Re: Security for various IETF services Scott Brim
- Re: Security for various IETF services Ted Lemon
- Re: Security for various IETF services Dick Franks
- Re: Security for various IETF services Phillip Hallam-Baker
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services Yoav Nir
- Re: Security for various IETF services Stephen Farrell
- RE: Security for various IETF services l.wood
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services Stephen Farrell
- Re: Security for various IETF services Yoav Nir
- Re: Security for various IETF services Noel Chiappa
- Re: Security for various IETF services Phillip Hallam-Baker
- Re: Security for various IETF services Dave Crocker
- Re: Security for various IETF services Ted Lemon
- Re: Security for various IETF services Theodore Ts'o
- Re: Security for various IETF services Tim Bray
- Re: Security for various IETF services Steve Crocker
- Re: Security for various IETF services Dave Cridland
- Re: Security for various IETF services Randall Gellens
- Re: Security for various IETF services Dave Crocker
- Re: Security for various IETF services Phillip Hallam-Baker
- Re: Security for various IETF services Stephen Farrell
- Re: Security for various IETF services Theodore Ts'o
- Re: Security for various IETF services Phillip Hallam-Baker
- Re: Security for various IETF services Ted Lemon
- Re: Security for various IETF services Phillip Hallam-Baker
- Re: Security for various IETF services Phillip Hallam-Baker
- Web of trust at Internet Scale Sam Hartman
- Re: Security for various IETF services Dave Cridland
- Re: Security for various IETF services Dave Cridland
- Re: Security for various IETF services Mark Andrews
- Re: Security for various IETF services Theodore Ts'o
- Re: Security for various IETF services Jelte Jansen
- Re: Security for various IETF services Stephen Kent