Re: [keyassure] Objective: Restrictive versus Supplementary Models

Martin Rex <mrex@sap.com> Wed, 30 March 2011 21:54 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 6E07A3A6AC8 for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 14:54:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.219
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAi1ZQXtKaz3 for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 14:53:59 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 498D83A6ABD for <keyassure@ietf.org>; Wed, 30 Mar 2011 14:53:59 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (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 <mrex@sap.com>
Message-Id: <201103302155.p2ULtaUI028846@fs4113.wdf.sap.corp>
To: ekr@rtfm.com (Eric Rescorla)
Date: Wed, 30 Mar 2011 23:55:36 +0200 (MEST)
In-Reply-To: <AANLkTikS3qg=r30bff8C-KGMSHOpgK=oJft3qEMnM28M@mail.gmail.com> 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
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 21:54:00 -0000

Eric Rescorla wrote:
> 
> Martin Rex <mrex@sap.com> 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.


-Martin