Re: [keyassure] Objective: Restrictive versus Supplementary Models

"Richard L. Barnes" <rbarnes@bbn.com> Wed, 30 March 2011 20:38 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 59C423A6BC7 for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 13:38:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.55
X-Spam-Level:
X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 NQ+ocSVCLkUQ for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 13:38:29 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 83B523A6BC5 for <keyassure@ietf.org>; Wed, 30 Mar 2011 13:38:29 -0700 (PDT)
Received: from [128.89.255.154] (port=60612 helo=dhcp-436b.meeting.ietf.org) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1Q52BN-000JjQ-NT; Wed, 30 Mar 2011 16:40:02 -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: <04AAADD9-69E1-43E5-8957-E951C69B332B@nzrs.net.nz>
Date: Wed, 30 Mar 2011 22:39:57 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1996B7AF-9711-48FD-92E1-BE8FC653E5BE@bbn.com>
References: <AANLkTik1Uzd8XSZzopBBDHywrhSjsBQYxC91BZXdkMwg@mail.gmail.com> <0AE869F3-0BBB-485F-8CDD-EC1B70EBB9B2@bbn.com> <m3pqp8fvoz.fsf@jhcloos.com> <F1AC4325-EA91-4570-A423-F14B178B3965@bbn.com> <DF4DAFFC-90DC-4AF3-88F8-9C19D39E2965@nzrs.net.nz> <AANLkTimbPj3iTofAo5ic7E=LS3ZtXyO5Gq=yR8fzB08d@mail.gmail.com> <04AAADD9-69E1-43E5-8957-E951C69B332B@nzrs.net.nz>
To: Jay Daley <jay@nzrs.net.nz>
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: Wed, 30 Mar 2011 20:38:30 -0000

To re-focus this discussion, I would just like to point out that whether DNSSEC is REQUIRED or RECOMMENDED is not material to the structure of the use case.  We can have that debate when it comes time to decide on mechanism.

--Richard



On Mar 30, 2011, at 10:27 PM, Jay Daley wrote:

> 
> On 31/03/2011, at 9:17 AM, Eric Rescorla wrote:
> 
>>>>> RLB> 1. Cert-lock / CA-lock
>>>>> RLB> 1.3. DNSSEC RECOMMENDED, not REQUIRED; attacker can only cause connection failure
>>>>> 
>>>>> If the attacker injects fake dns records pointing to a fake server, they
>>>>> can include a dane rr.  It only makes the attack slightly harder, doesn't it?
>>>> 
>>>> Yes, but as ekr pointed out, injecting fake DANE RRs can only cause the connection to fail, it won't result in the client connecting to a bogus server.   That's why it's RECOMMENDED instead of REQUIRED.
>>> 
>>> That's still potentially a devastating DOS attack if done well and against an important target.  Worthy of a REQUIRED for that alone.
>>> 
>>> There is also the layer 9 interpretation issue here - if we say that DANE in its entirety requires DNSSEC then that message can be shouted loud and clear, reinforced and hopefully entrenched.  If we say that only some parts need it then people, for entirely fallible reasons, get confused, doubt DANE, can use this to attack DANE and so on.
>> 
>> 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?
> 
> If unsigned then the data should be ignored.  That exactly maps to the current situation, which gives a clean split between that or using DANE as an all-or-nothing improvement on top of that.  
> 
> Jay 
> 
>> 
>> -Ekr
> 
> 
> -- 
> Jay Daley
> Chief Executive
> .nz Registry Services (New Zealand Domain Name Registry Limited)
> desk: +64 4 931 6977
> mobile: +64 21 678840
>