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 (Michael StJohns)
Date: Tue, 5 Oct 2010 02:46:11 +0200 (MEST)
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