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

Phillip Hallam-Baker <> Tue, 05 October 2010 16:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E6D653A6EE7; Tue, 5 Oct 2010 09:55:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.391
X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tqB7+Ti84XEc; Tue, 5 Oct 2010 09:55:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6EF793A6CE1; Tue, 5 Oct 2010 09:55:52 -0700 (PDT)
Received: by wyi11 with SMTP id 11so7276403wyi.31 for <multiple recipients>; Tue, 05 Oct 2010 09:56:50 -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=qeACtmJpx0u9kcCTLV3iZjdvxy0T8R7wFirbWu1+KL8=; b=NruY3oASaX3h8schAzzn0BWcCQlZfMN7RJdXWxxEiJlRKKI2RIW03MQkfJKcVFEAvZ eyqNBxkgAAx2HYPsRquKrNQr5qQocVoVff+u0cR1pSM0nDav8dmWkIlvVH72tQLSGT5P tR0bB3s8p0jHDyjwoloafLtbzcSRaaUEG0IvI=
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=kvYMQAACMkcQdRT34B7BBMtTJemOf+JNB2EYyPxJnvhRMgoB6egk2Mywn+PpxLGdFr A6tvEOkoLSXyxURp7gtvq4YqWX9buDKiiNgNeC9iye64jlubvZTXo7DHyx4MqetPc9MQ TVIjSreHwza/0peiXrmUrHx6vuAeNaBOq6GY0=
MIME-Version: 1.0
Received: by with SMTP id 6mr9510457wec.24.1286297809910; Tue, 05 Oct 2010 09:56:49 -0700 (PDT)
Received: by with HTTP; Tue, 5 Oct 2010 09:56:49 -0700 (PDT)
In-Reply-To: <>
References: <> <1285970705.1984.136.camel@mattlaptop2.local> <> <> <>
Date: Tue, 5 Oct 2010 12:56:49 -0400
Message-ID: <>
From: Phillip Hallam-Baker <>
To: "Kemp, David P." <>
Content-Type: multipart/alternative; boundary=0016364d29bf08fb170491e18c77
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: Tue, 05 Oct 2010 16:55:55 -0000


When I originally looked at this scheme I thought that it was intended to
reduce the attack surface in the manner you describe.

Clearly if you have two controls, A and B and BOTH must be compromised, the
system is less likely to be compromised than either A or B.

But the design approach taken in the Hoffman et. al. proposal is that
publication of a DNSSEC assurance for a cert disables verification on the
PKIX chain unless the 'preferences' flag is set. This flag will be buried in
a base64 encoded sub-field encoding.

In practice only a proportion of clients will deploy this mechanism. So if A
is PKIX and B is DNSSEC, it will be possible for an attacker to succeed if
either A or B is compromised in one configuration and if either A or A and B
is compromised in the other.

People seem to be confusing the security of the cryptographic protocols with
the security of the infrastructures that support them. The weakest link in
any competently designed security scheme is people and processes. The PKIX
infrastructure has been operating as a security infrastructure for 15 years,
its flaws are reasonably well understood at this point. DNS on the other
hand is a non-security infrastructure that people appear to want to
immediately co-opt to duplicate functions of PKIX.

"What could possibly go wrong"

Given that the problem that instigated this proposal is mis-issue of a
certificate. It would appear to me that we should look at deploying controls
that reduce the probability of mis-issue of a certificate before we rush to
deploy a completely new validation scheme for certificates in the six month
timescale being proposed in this charter.

In particular, it would be rather useful to have controls of the form:

* Certificates only valid if issued into a certificate chain with specified
* Obtain additional authentication according to protocol X and key Y.

On Tue, Oct 5, 2010 at 12:32 PM, Kemp, David P. <>wrote;wrote:

> You are confusing attack surface with vulnerability.  Without getting
> into technology specifics, if A .and. B must be successfully attacked in
> order to cause a problem, then having two systems can only reduce the
> vulnerability even though there are more places to attack.
> If the problem is availability, then the best strategy is redundancy -
> use multiple sources for a single information item.  If the problem is
> integrity, the best strategy is diversity - use different sources for
> different information items.  If either source gives the wrong answer
> you fail, but fail safely.  (Redundancy and diversity can be combined of
> course, but then combining rules such voting thresholds have to be
> specified).
> For the DNS/PKI case, if A is an IP address for a dnsname and B is a
> public key for a dnsname, then it is necessary to attack the sources of
> A and B in order to successfully spoof a named server.  If A and B come
> from the same system (e.g., DNS) it is necessary to attack only that
> system.  If they come from different systems (DNS and PKI) then it is
> necessary to attack both.  Attacking only one may cause an availability
> failure, but not an integrity failure.
> Dave
> -----Original Message-----
> From: [] On Behalf Of
> Ben Laurie
> 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.