Re: [keyassure] Objective: Restrictive versus Supplementary Models

"Richard L. Barnes" <rbarnes@bbn.com> Thu, 31 March 2011 13:27 UTC

Return-Path: <rbarnes@bbn.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 90D8228C170 for <keyassure@core3.amsl.com>; Thu, 31 Mar 2011 06:27:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.553
X-Spam-Level:
X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, 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 0E6xlpD7GGxV for <keyassure@core3.amsl.com>; Thu, 31 Mar 2011 06:27:48 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 7255828C16E for <keyassure@ietf.org>; Thu, 31 Mar 2011 06:27:47 -0700 (PDT)
Received: from [128.89.255.156] (port=49970 helo=[130.129.71.95]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1Q5HwD-00037C-3M; Thu, 31 Mar 2011 09:29:25 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <rbarnes@bbn.com>
In-Reply-To: <201103311302.p2VD2AWx020816@fs4113.wdf.sap.corp>
Date: Thu, 31 Mar 2011 15:29:18 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <E10206C6-2A07-4C76-8C21-C7E889FD99BB@bbn.com>
References: <201103311302.p2VD2AWx020816@fs4113.wdf.sap.corp>
To: mrex@sap.com
X-Mailer: Apple Mail (2.1082)
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: Thu, 31 Mar 2011 13:27:50 -0000

So it's a social engineering attack?  Might as well just send an email trojan.

This is the same result as
-- Hijacking the TCP session and feeding in a fake cert 
-- Spoofing the A record and sending the client to the wrong host (like ekr said)

--Richard



On Mar 31, 2011, at 3:02 PM, Martin Rex wrote:

> Eric Rescorla wrote:
>> 
>> On Thu, Mar 31, 2011 at 2:38 AM, Martin Rex <mrex@sap.com> wrote:
>>> Martin Rex wrote:
>>>> 
>>>>> 
>>>>> I think this is an important consideration. However a relevant
>>>>> question for a 2119-level MUST seems to be whether we wish to have
>>>>> this data rejected if not DNSSEC signed.
>>>>> What's your view on that?
>>>> 
>>>> I'm much less worried about false positives resulting in DoS, which
>>>> can be more easily achieved attacking at the network layer (IP, TCP).
>>> 
>>> Actually, a DoS based on spoofing an DANE TLSA record with incorrect
>>> data and a long TTL into a DNS cache might turn out to be devastatingly
>>> effective when unsiged TLSA records are accepted.
>> 
>> How is this different from a spoofed A record with a long TTL?
> 
> In a first round of attack, the attacker inserts a fake unsigned
> TLSA record (DNS poisoning) that the victim is accessing with TLS
> frequently and where the DNS admin is not using DNSSEC.
> 
> After constantly running into validation failures although one is
> connecting to the correct server and gets presented the correct
> TLS server cert, either his help desk or the victim will disable DANE
> or switch to a browser that doesn't have it yet.  At that point
> the victim becomes vulnerable to mis-issued certs even for sites
> where the DNS admin uses DANE with DNSSEC.
> 
> -Martin
> 
> 
> _______________________________________________
> keyassure mailing list
> keyassure@ietf.org
> https://www.ietf.org/mailman/listinfo/keyassure