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

"Jeffrey A. Williams" <> Mon, 04 October 2010 21:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 241E33A70C3; Mon, 4 Oct 2010 14:14:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.646
X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[AWL=0.953, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bR-3S5CzXLup; Mon, 4 Oct 2010 14:14:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0F1423A70BB; Mon, 4 Oct 2010 14:14:23 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327;; b=bPsxfn/51kXJnyXpm9oYgoxEnZyG/LCnvPF48iGnYvYniNmDiRZuF9Htg51naYuM; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [] ( by with esmtpa (Exim 4.67) (envelope-from <>) id 1P2sNT-0000IG-UP; Mon, 04 Oct 2010 17:15:19 -0400
Received: from by with HTTP; Mon, 4 Oct 2010 17:15:19 -0400
Message-ID: <>
Date: Mon, 4 Oct 2010 16:15:19 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <>
To: Michael StJohns <>,,,,
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688d304796be347e02cac8c2b5d708faa58350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
Subject: Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "Jeffrey A. Williams" <>
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 21:14:27 -0000

Michael and all,

  Nice outline.  What still bothers me is all this is still tied
to trust anchors.  How do we or anyone know or do about a trust
anchor that has been corrupted or otherwise breached?  It is likely
that the knowing of same will be delayed by some time factor and the
potential damage assessment may take even longer.  So there is a real
likelihood of potential harm here...

  Secondly, the same condition could/will apply to CA's Cert Database
with similar results. As some of us already know and has been detected,
reported and documented a few of the larger and well known CA's have had
their Cert databases breached leaving Cert holders from those CA's in
a very uncomfortable if not dangerous position on a number of levels.

-----Original Message-----
>From: Michael StJohns <>
>Sent: Oct 4, 2010 1:30 PM
>Subject: Re: [TLS] [pkix]   Cert Enumeration and Key Assurance With  DNSSEC
>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.  
>TLS mailing list
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
Phone: 214-244-4827