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

Marsh Ray <marsh@extendedsubset.com> Mon, 04 October 2010 15:13 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 A94763A6FEC; Mon, 4 Oct 2010 08:13:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.068
X-Spam-Level:
X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[AWL=0.531, 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 211YBrjouAxH; Mon, 4 Oct 2010 08:13:08 -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 179093A6FD0; Mon, 4 Oct 2010 08:11:27 -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 1P2miF-000Gpx-CG; Mon, 04 Oct 2010 15:12:23 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 2327D6018; Mon, 4 Oct 2010 15:12:21 +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: U2FsdGVkX1/RqO921MeCtQuFarZ58MlTmiUgl0nkbFs=
Message-ID: <4CA9EED5.5050006@extendedsubset.com>
Date: Mon, 04 Oct 2010 10:12:21 -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: mrex@sap.com
References: <201010041437.o94EbTHT029454@fs4113.wdf.sap.corp>
In-Reply-To: <201010041437.o94EbTHT029454@fs4113.wdf.sap.corp>
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: 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