Re: [keyassure] Objective: Restrictive versus Supplementary Models

Jay Daley <jay@nzrs.net.nz> Wed, 30 March 2011 20:25 UTC

Return-Path: <jay@nzrs.net.nz>
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 2425C3A69AB for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 13:25:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 hwYM+1L61C18 for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 13:25:58 -0700 (PDT)
Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 3C4BC3A68F4 for <keyassure@ietf.org>; Wed, 30 Mar 2011 13:25:58 -0700 (PDT)
Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 107C32CE004; Thu, 31 Mar 2011 09:27:41 +1300 (NZDT)
Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ob4yOy5pMUg; Thu, 31 Mar 2011 09:27:41 +1300 (NZDT)
Received: from [192.168.22.200] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id C42422DB35F; Thu, 31 Mar 2011 09:27:40 +1300 (NZDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Jay Daley <jay@nzrs.net.nz>
In-Reply-To: <AANLkTimbPj3iTofAo5ic7E=LS3ZtXyO5Gq=yR8fzB08d@mail.gmail.com>
Date: Thu, 31 Mar 2011 09:27:36 +1300
Content-Transfer-Encoding: quoted-printable
Message-Id: <04AAADD9-69E1-43E5-8957-E951C69B332B@nzrs.net.nz>
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>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.1084)
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:25:59 -0000

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