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

Martin Rex <mrex@sap.com> Mon, 04 October 2010 14:36 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 676433A6FC4; Mon, 4 Oct 2010 07:36:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.836
X-Spam-Level:
X-Spam-Status: No, score=-9.836 tagged_above=-999 required=5 tests=[AWL=0.413, 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 HHMoG11GZj5U; Mon, 4 Oct 2010 07:36:40 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 3531E3A6FBE; Mon, 4 Oct 2010 07:36:38 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o94EbUkK001001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Oct 2010 16:37:30 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201010041437.o94EbTHT029454@fs4113.wdf.sap.corp>
To: hallam@gmail.com (Phillip Hallam-Baker)
Date: Mon, 4 Oct 2010 16:37:29 +0200 (MEST)
In-Reply-To: <AANLkTik4MeDWDRxXLkPd8k6HPVeKY9_7p4FQWzyXwvFD@mail.gmail.com> from "Phillip Hallam-Baker" at Oct 2, 10 11:30:27 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: Mon, 04 Oct 2010 14:36:41 -0000

Phillip Hallam-Baker wrote:
> 
> The attack surface is the number of paths that are open to an attacker.
> 
> In the current model there is only one trust path, the PKIX path.
> 
> In the new model, the attacker has a choice of trust paths, the PKIX path
> and the DNSSEC path and they can attack either of them.

The PKI-based attack surface includes each and every single CA that
is signed under one of the existing >100 pre-configured trust anchors
shipping with browsers.  An attacker is free to choose to attack
any single one of these CAs and/or their issuing/validation procedures.

Trusting Certificates that are distributed under protection of DNSSEC
would amount to one additional trust anchor.
 
> 
> 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.

Therefore, security-wise, trusting Certificates that are
distributed through DNSSEC for no-prompt server endpoint identification
is more secure than the TLS PKI pre-configured trusted scheme, and
it does not add any new attack surface.  Only when server certificates
are manually verified by end users, other information from these
certificates besides the DNS f.q.d.n might be considered in
the end users decision to trust a server cert.

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.


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.


-Martin