Re: Security for various IETF services

Mark Andrews <marka@isc.org> Fri, 11 April 2014 00:32 UTC

Return-Path: <marka@isc.org>
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 4DFB21A03AA for <ietf@ietfa.amsl.com>; Thu, 10 Apr 2014 17:32:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.873
X-Spam-Level:
X-Spam-Status: No, score=-3.873 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, 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 TN7YyNiaO2R4 for <ietf@ietfa.amsl.com>; Thu, 10 Apr 2014 17:32:42 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF591A038A for <ietf@ietf.org>; Thu, 10 Apr 2014 17:32:41 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 915AC34941D; Fri, 11 Apr 2014 00:32:36 +0000 (UTC) (envelope-from marka@isc.org)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id AAC7E160066; Fri, 11 Apr 2014 00:34:21 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 75E92160047; Fri, 11 Apr 2014 00:34:21 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id F1A171365D59; Fri, 11 Apr 2014 10:32:31 +1000 (EST)
To: Theodore Ts'o <tytso@mit.edu>
From: Mark Andrews <marka@isc.org>
References: <20140409154919.11E6118C106@mercury.lcs.mit.edu> <534580AF.4080602@dcrocker.net> <20140409200814.GA15303@thunk.org> <3C46B827-BFFC-4A9E-B600-A1E79C839970@shinkuro.com> <20140410141406.GF15925@thunk.org>
Subject: Re: Security for various IETF services
In-reply-to: Your message of "Thu, 10 Apr 2014 10:14:06 -0400." <20140410141406.GF15925@thunk.org>
Date: Fri, 11 Apr 2014 10:32:31 +1000
Message-Id: <20140411003231.F1A171365D59@rock.dv.isc.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/oknewnk4jWTYAoWCiw1-08mOIic
Cc: Noel Chiappa <jnc@mercury.lcs.mit.edu>, 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: Fri, 11 Apr 2014 00:32:49 -0000

In message <20140410141406.GF15925@thunk.org>, Theodore Ts'o writes:
> On Wed, Apr 09, 2014 at 04:15:53PM -0400, Steve Crocker 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.
> 
> DNSSEC basically has the same properties as the "race to the bottom
> certifying authorities" model, except it's a "race to the bottom of
> the DNS registraries" --- and some cases, the same company runs both a
> CA and a DNS registry.  "Meet the new boss, same as the old boss"....

No quite the same.  A CA could issue a cert without any checking
for any domain.  Here you need to be the registrar of record to add
records to the registry.  Also a registry can only add records for
the namespace it manages not any arbitary name.

So to get a bad DS added you need to be a corrupt registry or a
corrupt employee of registry or you need to compromise the registrants
credentials or you need to succeed in transfering the zone to you.

The registry can provide some protection for some of these threats.

This is a smaller attack surface than the plain CA attack surface.

> So if you're willing to disclaim the amount of trust that the CA
> system purports to provide, it's really a question of "IPSEC" vs "TLS"
> --- i.e., at which layer of the stack you are applying the protection.
> 
> Cheers,
> 
> 					- Ted
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org