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

Michael StJohns <mstjohns@comcast.net> Mon, 04 October 2010 18:29 UTC

Return-Path: <mstjohns@comcast.net>
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 641533A7050 for <tls@core3.amsl.com>; Mon, 4 Oct 2010 11:29:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.345
X-Spam-Level:
X-Spam-Status: No, score=-102.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 8q+Z43byqOmg for <tls@core3.amsl.com>; Mon, 4 Oct 2010 11:29:36 -0700 (PDT)
Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 97E3C3A700E for <tls@ietf.org>; Mon, 4 Oct 2010 11:29:35 -0700 (PDT)
Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta05.westchester.pa.mail.comcast.net with comcast id EdVf1f0050vyq2s55iWXoY; Mon, 04 Oct 2010 18:30:31 +0000
Received: from Mike-PC3.comcast.net ([68.83.217.57]) by omta05.westchester.pa.mail.comcast.net with comcast id EiWX1f0031EtFYL3RiWX1e; Mon, 04 Oct 2010 18:30:31 +0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 04 Oct 2010 14:30:29 -0400
To: pkix@ietf.org,dnsop@ietf.org,saag@ietf.org,tls@ietf.org
From: Michael StJohns <mstjohns@comcast.net>
In-Reply-To: <4CA9EED5.5050006@extendedsubset.com>
References: <201010041437.o94EbTHT029454@fs4113.wdf.sap.corp> <4CA9EED5.5050006@extendedsubset.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <20101004182935.97E3C3A700E@core3.amsl.com>
X-Mailman-Approved-At: Mon, 04 Oct 2010 13:17:18 -0700
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 18:29:59 -0000

Hi -

DNSSEC seems to be picking on PKIX and vice versa - maybe the right answer is both?


DNSSEC provides a "secure" association FROM the name TO the IP address.  But the DNS domain owner tends not to be the host owner so this asserted association may not reflect the intent of the host owner.  Also, DNSSEC doesn't protect from IP hijacking (re-routing).

PKIX provides a "secure" association TO/FROM "a" name to a public key.  The host owner holds the private key and can prove "ownership" of the related public key.  But the host owner tends not to be the domain owner so the asserted association may not reflect the intent of the DNS domain owner.


What if - the PKIX certificate for the host contained a "permit" for the name signed by the DNS owner?  A signature over the hash of the public key in the certificate, and the DNS name - and maybe some expiration info verifiable by the data in DNSSEC?


The path goes something like:

1) Use DNS and DNSSEC to find the host (or even just DNS)
2) Use TLS to grab the certificate
3) Verify the certificate using the PKIX path to a trust anchor
4) Verify the host knows the private key related to the host certificate
5) Verify the extension in the certificate was signed by the domain's DNSSEC key (pick one of special key, KSK or ZSK)
6) Verify the name offered in the certificate matches the DNS name looked up.

You've verified that:
a) The zone owner has assigned the name to the owner of the cert's private key
b) The host owner has agreed the host has the DNS name.
c) The IP to Name mapping (what might be in the PTR record and signed under DNSSEC - maybe).

The DNSSEC name to IP address mapping becomes irrelevant for trust purposes which means that IP hijacking is no longer an issue.

A random PKIX forming a certificate with a DNS name in it can't form one that proves the name assignment from the DNS, so the large set of PKIX trust anchors becomes less of an issue.  

Mike