Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC

Phillip Hallam-Baker <> Sun, 03 October 2010 03:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BDB4A3A6BDF; Sat, 2 Oct 2010 20:29:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.413
X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1oDbC22pZ+Bn; Sat, 2 Oct 2010 20:29:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 748383A6A76; Sat, 2 Oct 2010 20:29:36 -0700 (PDT)
Received: by wyi11 with SMTP id 11so4751547wyi.31 for <multiple recipients>; Sat, 02 Oct 2010 20:30:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=btDpdCAjR4uhSZAuFt8q+P9kcHUv+6yQttznWNOEe64=; b=Tdw32dAOahL39dgkTTWkts6hybFmtvNGLskLuqHPpVNl1tT4fYz4J4tPMMIa59esO+ sQ6mlkePvaw3wyNtB0PMUGi8TkFuOXPu5RNI/GwmYU7lsIcy4mub2pJDu+dZ+ffIUgWh WUjv8tJBM/9J4z/nvkG62C9fsyAMFTngekGeU=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=mup5bO1KSYCXQIueGoUoYpGSWM+0nu/qp2wmE7WgHaypgqjbRvsfDtnFFCfVPU/VQ6 Q7kFiIjgJp14eJnM3GthA7pXX6eZX0alpz0cuK1bRhMAdmApe0zqSUAI9nn68QG3HbX9 05VJFfcIQv1t6T8BnHsjFQ5S8sEK2LWFQUL3I=
MIME-Version: 1.0
Received: by with SMTP id x10mr2604010wec.57.1286076627371; Sat, 02 Oct 2010 20:30:27 -0700 (PDT)
Received: by with HTTP; Sat, 2 Oct 2010 20:30:27 -0700 (PDT)
In-Reply-To: <>
References: <> <1285970705.1984.136.camel@mattlaptop2.local> <> <> <>
Date: Sat, 2 Oct 2010 23:30:27 -0400
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Marsh Ray <>
Content-Type: multipart/alternative; boundary=000e0cdf8c9087491b0491ae0c6c
Subject: Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 03 Oct 2010 03:29:38 -0000

The attack surface is the number of paths that are open to an attacker.

In the current model there is only one trust path, the PKIX path.

In the new model, the attacker has a choice of trust paths, the PKIX path
and the DNSSEC path and they can attack either of them.

The problem with the DNSSEC path is that it is vulnerable to attacks against
the information input to the DNS system. The weakest link there is the
safeguards on registration of the DNS names.

I think that whenever a proposal of this type is brought that we should be
told all the considerations and all the events that are motivating the

On Sat, Oct 2, 2010 at 9:49 PM, Marsh Ray <> wrote:

> On 10/02/2010 03:16 PM, Ben Laurie wrote:
>> On 1 October 2010 16:15, Phillip Hallam-Baker<>  wrote:
>>> The problem with that approach is that the attacker now has two
>>> infrastructures that they can attack rather than just one.
>> If I deploy the DNS solution, stating that DNS is authoritative, then
>> my attack surface now excludes all CAs. How is that an increase in
>> attack surface?
>> Contrast with today's situation, where my attack surface is increased
>> on a regular basis by the introduction of new CAs, without any
>> consultation with me at all.
> The thing we have to to keep in mind here is that this "attack surface" is
> largely determined on the client of the equation. In other words, if you
> attempt to set policy through DNS, it only applies to clients who choose to
> respect it. And clients do have that annoying habit of not consulting the
> server admins (or the users for that matter) before changing their trust. We
> can blame Netscape, they intentionally set it up this way (and are no longer
> around to defend themselves).
> How much consistency is there in the current crop of PKI rules? What if
> DNSSEC info conflicts with other info?
> Vendors of client software sometimes give themselves a root cert in the
> client, or at least have a close relationship with some of their CAs.
> There's a lot of money at stake, how eager will they be to allow sites to
> opt-out of that trust? Some of them also sell TLS MitM interception
> products.
> The possibility that the bulk of clients will respect DNSSEC records which
> cut their CAs out of the trust equation any time soon seems a bit remote. We
> might as well be discussing the deprecation of SSLv3. It could happen
> eventually, but probably not in the near term.
> In the meantime, we'd end up with the DNS root effectively having the power
> of yet another CA. Except that it's not, because the various arms of ICANN
> and VeriSign/Symantec are probably already trusted many times over.
> I've seen it said that during the pre-deployment phase, the designers and
> promoters of DNSSEC denied they were making a replacement PKI. But the
> discussion now is to what extent it is inevitable. Regardless, if this is
> PKI 2.0 getting ready to usurp the throne, we should at least ensure that
> its a legitimately designed trust model this time rather than stumbling into
> whatever serves to enable some set of business agreements.
> - Marsh