Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC
Martin Rex <mrex@sap.com> Tue, 05 October 2010 00:45 UTC
Return-Path: <mrex@sap.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 8235C3A6D27; Mon, 4 Oct 2010 17:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.858
X-Spam-Level:
X-Spam-Status: No, score=-9.858 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 7uSitcw2WQWp; Mon, 4 Oct 2010 17:45:19 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 081F93A6C73; Mon, 4 Oct 2010 17:45:18 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o950kCXZ011877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Oct 2010 02:46:12 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201010050046.o950kBPe005266@fs4113.wdf.sap.corp>
To: mstjohns@comcast.net
Date: Tue, 05 Oct 2010 02:46:11 +0200
In-Reply-To: <20101004182935.97CE53A705B@core3.amsl.com> from "Michael StJohns" at Oct 4, 10 02:30:29 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
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
Reply-To: mrex@sap.com
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: Tue, 05 Oct 2010 00:45:20 -0000
Michael StJohns wrote: > > DNSSEC seems to be picking on PKIX and vice versa > - maybe the right answer is both? In theory, PKIX could provide real value. In practice, the PKIX abuse commonly described as "TLS PKI" that performs a non-popup server endpoint identification with the help of target DNS hostnames has infinitesimal close to zero value over DNSSEC. Conceptually, limiting the certificates that can be used to provide servers on specific DNS hostnames to certificates explicitly listed by the DNS admin would significantly reduce the huge attack surface of the existing "TLS PKI" with >100 independent pre-configured trust-anchors in most TLS client software. > > 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). Incorrect characterisation. DNSSEC provides only for secure distribution of DNS records. Whether the distributed DNS records are accurate or trustworthy is a completely distinct issue. > > PKIX provides a "secure" association TO/FROM "a" name to a public key. This "secure" association is limited to specific "vetted" attributes (which may or may not be described in a legalese Certificate Practice Statement (CPS)), with one notable and serious exception: Any occurrence of a DNS hostname in a PKIX cert is based entirely and completely on the DNS delegation records, and all of the popular non-prompting server endpoint identification completely ignores all carefully reviewed cert attributes and relies _completely_ on the DNS hostnames based on the DNS delegation records. > > 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. While this may be true in practice, the domain owner is a person that is definitely entitled to get certs issued for hostnames in his domain from most (probably all) "TLS PKI CAs" and the domain owner is also the one that can create and is entitled to distribute arbitrary DNS records in his DNS domain through DNS and DNSSEC protocols. Authentication that should reliably exclude the DNS admin for a servers DNS hostname from acquiring a "valid" server cert, will need to completely ban the DNS hostname from the server endpoint identification. One means to do this would be to securly authenticate the server by his public key, also called "certificate pinning", also mentioned here http://www.w3.org/TR/wsc-ui/#selfsignedcerts Selective trust and trust being affected by repeated encounter is evolutionary heritage and intrinsic to every mammal and most human beings. Unfortunately, some TLS-clients make it increasingly difficult to practice such evolutionary proven approaches to server endpoint identification. -Martin
- [TLS] Cert Enumeration and Key Assurance With DNS… Phillip Hallam-Baker
- Re: [TLS] Cert Enumeration and Key Assurance With… Ben Laurie
- Re: [TLS] Cert Enumeration and Key Assurance With… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Matt McCutchen
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Ben Laurie
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Marsh Ray
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Peter Gutmann
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Phillip Hallam-Baker
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Tony Finch
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Michael StJohns
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Tony Finch
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Marsh Ray
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Ralph Holz
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Stephen Farrell
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Geoffrey Keating
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] Cert Enumeration and Key Assurance With… Ondřej Surý
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Jeffrey A. Williams
- Re: [TLS] Cert Enumeration and Key Assurance With… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Phillip Hallam-Baker
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Jakob Schlyter
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Michael StJohns
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Andrew Sullivan
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Jeffrey A. Williams
- [TLS] OtherCerts & pinning (Was: Re: [pkix] Cert … Stephen Farrell
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Kemp, David P.
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Ralph Holz
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Ondřej Surý
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Jeffrey A. Williams
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Seth David Schoen
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Marsh Ray
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Stephen Kent
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Paul Hoffman
- Re: [TLS] Cert Enumeration and Key Assurance With… Nicolas Williams
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Marsh Ray
- Re: [TLS] [saag] [pkix] Cert Enumeration and Key … Peter Gutmann
- Re: [TLS] [saag] [pkix] Cert Enumeration and Key … Yaron Sheffer
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Henry B. Hotz
- Re: [TLS] [saag] [pkix] Cert Enumeration and Key … der Mouse
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Carl Wallace
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Jeffrey A. Williams
- Re: [TLS] [DNSOP] [saag] [pkix] Cert Enumeration … Doug Barton
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Bruno Harbulot
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Jeffrey A. Williams
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Paul Wouters