Re: [keyassure] Objective: Restrictive versus Supplementary Models

Martin Rex <mrex@sap.com> Wed, 30 March 2011 18:17 UTC

Return-Path: <mrex@sap.com>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E21428C19A for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 11:17:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.218
X-Spam-Level:
X-Spam-Status: No, score=-10.218 tagged_above=-999 required=5 tests=[AWL=0.031, 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 l3hgO2yyR-AO for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 11:17:06 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 712E528C195 for <keyassure@ietf.org>; Wed, 30 Mar 2011 11:17:06 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p2UIIcO8020868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Mar 2011 20:18:43 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201103301818.p2UIIbcA016146@fs4113.wdf.sap.corp>
To: ekr@rtfm.com (Eric Rescorla)
Date: Wed, 30 Mar 2011 20:18:37 +0200 (MEST)
In-Reply-To: <AANLkTik1Uzd8XSZzopBBDHywrhSjsBQYxC91BZXdkMwg@mail.gmail.com> from "Eric Rescorla" at Mar 30, 11 10:48:53 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: keyassure@ietf.org
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyassure>
List-Post: <mailto:keyassure@ietf.org>
List-Help: <mailto:keyassure-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Mar 2011 18:17:07 -0000

Eric Rescorla wrote:
> 
> 1. Protecting against CA mis-issue (as in CA/cert lock).
> 
> In the first case, the idea would be that the relying party would go
> through its ordinary validation logic and if that failed, would reject
> the certificate. However, if the validation succeeded,
> it would check DNS and if that check failed, would then reject the
> certificate. Only if both checks succeeded would the certificate
> be accepted. [0] The objective of this type of mechanism would be
> simply to defend against unauthorized certificate issuance.
> Note that in this case, the DANE data need not be DNSSEC secured,
> because an attacker who tampers with it will solely be able to
> cause a connection failure, and in many cases (TLS, SSH, etc.)
> an attacker with those capabilities can tamper with
> the A record and block the connection that way.

Maybe I'm dense at the moment, but I don't understand
"the DANE data need not be DNSSEC secured".

Without DNSSEC, you have a vulnerability, because you can not
enforce a CA or EE cert lock.  An attacker can DNS-spoof DANE records
for the mis-issued certs of his choice or DNS-spoof the absence
of DANE records (and the absence of DANE records will be quite
common for more than just a few days).


>
> 2. Allowing TLS to work without getting a certificate from one of the
>    established trust anchors.
>
>  [...]
>
> The draft to some extent conflates these two objectives, since it
> *both* injects a new trust anchor and restricts the list of potential
> certificates. It does not allow you to simply restrict
> the list of CAs/certificates without also injecting a new trust point.

Personally, I would also prefer if the information conveyed through
DANE would include a tag that clearly distinguishes "CA/cert lock" (for
a server cert issued under the traditional TLS X.509 PKI of browsers)
from a certificate path validation based solely on DNSSEC trust.

But ultimately, whoever gains control over the DNSSEC zone contents
will be able to preempt the validation under the traditional TLS X.509 PKI
for a server cert by supplying appropriately crafted DNSSEC-signed DANE
records.

Therefore, the existence of DANE will make DNS admins much more interesting
targets for attacks (as an alternative to attacking issuing procedures
of commercial CAs).


-Martin