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

Marsh Ray <marsh@extendedsubset.com> Sun, 03 October 2010 01:48 UTC

Return-Path: <marsh@extendedsubset.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C127B3A6C5E; Sat, 2 Oct 2010 18:48:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.059
X-Spam-Level:
X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlPrUaJ5PNOE; Sat, 2 Oct 2010 18:48:29 -0700 (PDT)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id C92A03A6C43; Sat, 2 Oct 2010 18:48:29 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1P2DhY-0004yT-Um; Sun, 03 Oct 2010 01:49:21 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id DCEA86019; Sun, 3 Oct 2010 01:49:19 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX19QAxKUojgP+48vkGKoVKHPuEi7YSTaDAo=
Message-ID: <4CA7E120.6080701@extendedsubset.com>
Date: Sat, 02 Oct 2010 20:49:20 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8
MIME-Version: 1.0
To: Ben Laurie <benl@google.com>
References: <AANLkTinRWJZr7huuG+Ovh3sCCUnVZAghggAzmq7g6ERx@mail.gmail.com> <1285970705.1984.136.camel@mattlaptop2.local> <AANLkTi=cD1E=QoD3uRyhHyd6bUSgd9_ibgdM5iy1+9TR@mail.gmail.com> <AANLkTimtc1aT0r+oTJYpjixTSiE+gwpORszjPYz7y7PE@mail.gmail.com>
In-Reply-To: <AANLkTimtc1aT0r+oTJYpjixTSiE+gwpORszjPYz7y7PE@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: pkix@ietf.org, dnsop@ietf.org, saag@ietf.org, tls@ietf.org
Subject: Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Oct 2010 01:48:30 -0000

On 10/02/2010 03:16 PM, Ben Laurie wrote:
> On 1 October 2010 16:15, Phillip Hallam-Baker<hallam@gmail.com>  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