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

Marsh Ray <> Tue, 05 October 2010 18:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 72BFF3A6FC2; Tue, 5 Oct 2010 11:36:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, SARE_MILLIONSOF=0.315]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qnxI5AMZl1Si; Tue, 5 Oct 2010 11:36:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id ED26A3A7097; Tue, 5 Oct 2010 11:35:59 -0700 (PDT)
Received: from ([]) by with esmtpa (Exim 4.68) (envelope-from <>) id 1P3CNl-0005Km-Nc; Tue, 05 Oct 2010 18:36:57 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id 7086D6018; Tue, 5 Oct 2010 18:36:56 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX1+8ypa8RMu5rlKDWfvP1mXa36zdcsNGry8=
Message-ID: <>
Date: Tue, 05 Oct 2010 13:36:56 -0500
From: Marsh Ray <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100915 Thunderbird/3.0.8
MIME-Version: 1.0
To: Phillip Hallam-Baker <>
References: <> <1285970705.1984.136.camel@mattlaptop2.local> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "Kemp, David P." <>,,,,,
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 18:36:01 -0000

On 10/05/2010 11:56 AM, Phillip Hallam-Baker wrote:
> 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.


In practice, only a proportion of servers will deploy this mechanism 
until such time as Firefox and Chrome are willing to shut them off.

I've read that because DNSSEC records are large, some resolvers cannot 
pass them on. Testing a few months ago indicated that it worked on 
something like 4 out of 5 internet connections I tried it on. But it's 
quite possible that there are little wifi-router-firewall boxes in 
millions of homes that don't expect such large packets on port 53.

So clients will have to continue to operate in the absence of DNSSEC 
information for the forseeable future.

It's also reasonable to suspect that an attacker (who in our analysis is 
already presumed to have a fraudulent server cert and the ability to 
make use of it, i.e., MitM) would also be able to downgrade DNS to strip 
out this "preferences" flag (if some intermediate box isn't doing it 

Therefore the attacker may be able to choose to attack the via a DNSSEC 
problem (e.g., a website vuln at the site's DNS registrar) or via PKI 
(e.g., a rouge sub-CA). So the attack surface is, in fact, increased.

Unless I'm missing something about how DNSSEC prevents downgrade 
attacks, which is quite possible.

> 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.

Perhaps only because security designers have successfully washed their 
hands of the harder part of the problem?

> The PKIX infrastructure has been operating as a security
> infrastructure for 15 years, its flaws are reasonably well understood at
> this point.

That's a very nice way of saying it.

I would have said it this way:

     IT SUCKS!!!!

The fact that the national telephone company of Qwertystan can delegate 
a sub-CA that can delegate a sub-CA that can issue a certificate which 
enables the MitM of the connection between my notebook and my company's 
VPN server is a scandal. If anyone had ever proposed such a scheme to 
people who weren't already steeped in the status quo, they'd be laughed 
out of their industry.

> DNS on the other hand is a non-security infrastructure that
> people appear to want to immediately co-opt to duplicate functions of PKIX.

Rather than wanting to co-opt or duplicate the current PKI scheme, it 
may be that people are simply eager to rid themselves of it.

Not saying it's perfect, I honestly haven't looked into it very deeply, 
but DNSSEC holds a lot of promise:

1. It builds on top of DNS, which is reasonably mature.

2. It was designed for actual security with knowledge of modern attacks 
and the benefit of hindsight.

3. It was designed at all, rather than simply evolving to enable various 
sets of business deals.

4. It roots to one entity is ostensibly neutral and non-profit. They 
have a track record which can be evaluated. They largely own DNS anyway.

5. Domain holders already understand the need to handle their domain 
name registrations as super-critical assets.

6. It appears to delegate more control to the domain holder to define 
and authenticate his own data. He doesn't have to deal with weird "per 
server licensing" (whatever that means) agreements.

7. It appears to reduce or eliminate some recurring fees associated with 
server authentication.

Of course, this list leaves out anything bad about it. Possibly, it's 
worse on balance.

> "What could possibly go wrong"

Lots, particularly during the transition period when parallel systems 
must be trusted.

Which is why such a proposal needs a lot of thinking and real-world testing.

Which is why it would have been better for it to have been proposed earlier.

> 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

It's not a question of probability, it's the option of the attacker. If 
you have something worth protecting, you need to be defending against a 
targeted attack. The attacker may or may not have the capability to 
obtain a usable private key, but if he can, he can be expected to use 
it. So it's not a question of "probability if" but of "who", i.e., who 
are the attackers I wish to defend against.

There are may of users of the technology who do not desire to trust (or 
actively mistrust) many of the entities controlling CAs.

> 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 properties
> * Obtain additional authentication according to protocol X and key Y.

Anything limiting the number and scope of CAs would be an improvement.

But such improvements could have been implemented at any time 
previously, yet they were not. Maybe the prospect of DNSSEC replacing it 
will provide motivation for PKI to improve. But by then the train may 
already be rolling.

- Marsh