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

Marsh Ray <> Mon, 04 October 2010 15:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A94763A6FEC; Mon, 4 Oct 2010 08:13:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.068
X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[AWL=0.531, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 211YBrjouAxH; Mon, 4 Oct 2010 08:13:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 179093A6FD0; Mon, 4 Oct 2010 08:11:27 -0700 (PDT)
Received: from ([]) by with esmtpa (Exim 4.68) (envelope-from <>) id 1P2miF-000Gpx-CG; Mon, 04 Oct 2010 15:12:23 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id 2327D6018; Mon, 4 Oct 2010 15:12:21 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX1/RqO921MeCtQuFarZ58MlTmiUgl0nkbFs=
Message-ID: <>
Date: Mon, 04 Oct 2010 10:12:21 -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
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Mon, 04 Oct 2010 15:13:19 -0000

On 10/04/2010 09:37 AM, Martin Rex wrote:
> Phillip Hallam-Baker wrote:
>> 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.
> It seems that you do not realize that the entire TLS PKI security model,
> as far as the automatic / no-prompt "server endpoint identification" is
> concerned, has always been relying completely on that DNS data being
> accurate.

How do you figure that?

I can put an entry in /etc/hosts (do this all the time for testing) and 
DNS isn't even queried. Yet the server certificate is validated as usual.

> But keep in mind that few TLS clients (such as browsers), currently
> support "pinning" of PKIX-authenticated server certs, so that on future
> connects only the very same server cert (with user-authenticated
> attributes other than DNS f.q.d.n) will be accepted from that server.
> In is very common misbehaviour in TLS clients to accept arbitrary other
> server certs on future connects, as long as the DNS f.q.d.n matches.

Is there a spec saying this is invalid behavior?

> One thing that needs to be addressed/solved is the key/cert rollover
> for any TLS-Server, so that it is possible to list more than one
> server cert as "valid" for a Server through DNS, at least for the
> time of the transition/rollover.

If you're going to trust certs you get out of DNS, you might as well 
just put a self-signed organizational CA cert in there. Maybe that's 
what's being proposed.

Say, what's the link to the Internet Draft proposal we're discussing anyway?

- Marsh