Re: [keyassure] Objective: Restrictive versus Supplementary Models

Eric Rescorla <ekr@rtfm.com> Wed, 30 March 2011 22:13 UTC

Return-Path: <ekr@rtfm.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 DBF963A67EE for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 15:13:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.946
X-Spam-Level:
X-Spam-Status: No, score=-102.946 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 m4Agm+OsYTFQ for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 15:13:00 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id C836D3A6BDF for <keyassure@ietf.org>; Wed, 30 Mar 2011 15:12:59 -0700 (PDT)
Received: by iye19 with SMTP id 19so1962050iye.31 for <keyassure@ietf.org>; Wed, 30 Mar 2011 15:14:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.43.131.7 with SMTP id ho7mr1961833icc.171.1301523278789; Wed, 30 Mar 2011 15:14:38 -0700 (PDT)
Received: by 10.42.217.2 with HTTP; Wed, 30 Mar 2011 15:14:38 -0700 (PDT)
In-Reply-To: <201103302155.p2ULtaUI028846@fs4113.wdf.sap.corp>
References: <AANLkTikS3qg=r30bff8C-KGMSHOpgK=oJft3qEMnM28M@mail.gmail.com> <201103302155.p2ULtaUI028846@fs4113.wdf.sap.corp>
Date: Thu, 31 Mar 2011 00:14:38 +0200
Message-ID: <AANLkTimG7He5H3AXCphotJkbUiSSwnSMmuWMDjL4-FQM@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
To: mrex@sap.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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
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 22:13:01 -0000

On Wed, Mar 30, 2011 at 11:55 PM, Martin Rex <mrex@sap.com> wrote:
> 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.

I don't disagree with you about the facts of the situation, merely about how
they should be interpreted..

Best
-Ekr

> 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
>