Re: [keyassure] Objective: Restrictive versus Supplementary Models

Eric Rescorla <> Wed, 30 March 2011 19:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7A2D328C18B for <>; Wed, 30 Mar 2011 12:25:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.944
X-Spam-Status: No, score=-102.944 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id szaerreFabhk for <>; Wed, 30 Mar 2011 12:25:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 911B928C12E for <>; Wed, 30 Mar 2011 12:25:53 -0700 (PDT)
Received: by iye19 with SMTP id 19so1805685iye.31 for <>; Wed, 30 Mar 2011 12:27:32 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id iw7mr1461972icb.238.1301513252430; Wed, 30 Mar 2011 12:27:32 -0700 (PDT)
Received: by with HTTP; Wed, 30 Mar 2011 12:27:31 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Wed, 30 Mar 2011 21:27:31 +0200
Message-ID: <>
From: Eric Rescorla <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Mar 2011 19:25:54 -0000

On Wed, Mar 30, 2011 at 8:18 PM, Martin Rex <> wrote:
> 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).

It's obviously better if DANE is DNSSEC secured, but it's not dangerous
if they aren't signed, since that just brings you back to where you were
without DANE. However, the DANE records can be set with fairly long
expiries (like HSTS), thus providing a partial firewall against comodo-type