Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)

Shumon Huque <> Thu, 25 February 2010 20:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1B9DC28C28C for <>; Thu, 25 Feb 2010 12:16:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.783
X-Spam-Status: No, score=-0.783 tagged_above=-999 required=5 tests=[AWL=-1.817, BAYES_00=-2.599, FRT_EXPERIENCE=2.333, J_CHICKENPOX_36=0.6, SARE_BIZOP=0.7]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D0tSSJRjf+KM for <>; Thu, 25 Feb 2010 12:16:00 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 587ED28C1C9 for <>; Thu, 25 Feb 2010 12:15:52 -0800 (PST)
Received: by (Postfix, from userid 4127) id 95DA72789; Thu, 25 Feb 2010 15:18:03 -0500 (EST)
Date: Thu, 25 Feb 2010 15:18:03 -0500
From: Shumon Huque <>
To: Paul Wouters <>
Subject: Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/
Organization: University of Pennsylvania
Cc: Masataka Ohta <>, Phillip Hallam-Baker <>, Paul Hoffman <>, IETF Discussion <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Feb 2010 20:16:10 -0000

On Thu, Feb 25, 2010 at 11:55:03AM -0500, Paul Wouters wrote:
> On Thu, 25 Feb 2010, Phillip Hallam-Baker wrote:
> >If DNSSEC succeeds, the domain validated certificate business will
> >have to either transform or eventually die. I think that for most CAs,
> >the business opportunities from SSL+DNSSEC are greater than the
> >opportunities from the current DV SSL business. DNSSEC cannot deploy
> >unless the registrars have cryptography expperience, the CAs have that
> >experience.
> If you ask security researchers, it has been proven that CA's sacrificed
> security for profitability. The CA model has failed to work. 2 second
> validation based on email, md5 based * root certificates signed, etc etc.
> The last two years saw a significant amount of attacks against CA's, and
> CA's have seen their profit margin fall to near zero, so even if they
> wanted to, they cannot increase security (you ask me a confirmation for
> my cert, I'll go to this other ssl provider that doesn't).

I'll refrain from inserting the obligatory Matt Blaze CA quote
here :-)

> The time of outsourcing security to CA's is over.
> Paul

Exactly. What many of us would like to see is the ability for 
enterprises to issue X.509 certificates themselves for their own
application services. If we're going to have a global PKI,
the way I think it should work is that CA's higher up in the 
hierarchy should certify CA's below them (enterprises or
some trusted intermediaries) using 'name constraint's so that
the subordinate CA's can only issue certificates for subject
identities in the namespace for which they have authority. And
ideally the higher level CAs should be multi-lateral non-profits,
rather than states or for-profit corporations engaged in a 
collective race to the bottom.

The current situation with commercial CAs is beyond horrible. Just 
take a look at how many "root" CAs are embedded in your favorite 
browser, and with virtually no constraints on the name space in 
which they can issue certs. Do you really trust all of them? Any 
of them, whether by malice or by being tricked, can issue a certificate 
for any of your services. Our security is basically as good as the 
the CA with the laxest policies & worst security.

And in terms of functionality, they are woefully inadequate too.
Most of them can only issue certs for hostnames in subject or
subject alternative name dnsname fields. What if I want to deploy
a certificate with other types of extension fields to better
compartmentalize security or to enable new functionality, eg. URI, 
SRVName, a custom SAN, or application-service specific EKU fields? 
Allowing organizations to issue their own certificates allows them 
to deploy security infrastructure that actually addresses their needs.

Perhaps it's wishful thinking, but I kinda look forward to the
day that DNSSEC is widely deployed. I look forward to using SSHFP, 
IPSECKEY, and (a better version of) CERT to displace the broken
Internet PKI ..