Re: [keyassure] Objective: Restrictive versus Supplementary Models

Martin Rex <> Wed, 30 March 2011 21:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E07A3A6AC8 for <>; Wed, 30 Mar 2011 14:54:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.219
X-Spam-Status: No, score=-10.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rAi1ZQXtKaz3 for <>; Wed, 30 Mar 2011 14:53:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 498D83A6ABD for <>; Wed, 30 Mar 2011 14:53:59 -0700 (PDT)
Received: from by (26) with ESMTP id p2ULtbpb010065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Mar 2011 23:55:37 +0200 (MEST)
From: Martin Rex <>
Message-Id: <>
To: (Eric Rescorla)
Date: Wed, 30 Mar 2011 23:55:36 +0200 (MEST)
In-Reply-To: <> from "Eric Rescorla" at Mar 30, 11 09:27:31 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
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 21:54:00 -0000

Eric Rescorla wrote:
> Martin Rex <> wrote:
> >
> > 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
> problems.

I still don't understand.

As Bruce Schneier says "security must be evaluated not based
on how it works, but on how it fails".

DANE without DNSSEC is a vulnerability by itself, because it can
be abused by an attacker to make things work that shouldn't work
(the trust rooted to DNS case) and can create a false impression
about security that is not provided (the cert/CA lock case).

Verification of unsigned DANE TLSA records may cause a warm
fuzzy feeling for some, but does not provide any security
against a determined and powerful attacker.

Commodogate may have been a government-backed hack.  The may be
more such about which we don't know yet.  They could prevent OCSP-checks
by making the relevant requests fail at the network layer.
Similarly, they could prevent browser updates (with blacklists of
the mis-issued certs) at the network level.  And they could spoof
DNS replies as well.