Re: [keyassure] Objective: Restrictive versus Supplementary Models

Eric Rescorla <ekr@rtfm.com> Wed, 30 March 2011 20:16 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 D44C33A6A2A for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 13:16:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.945
X-Spam-Level:
X-Spam-Status: No, score=-102.945 tagged_above=-999 required=5 tests=[AWL=0.032, 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 IylpXaWbpgU3 for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 13:16:08 -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 0B8553A69AB for <keyassure@ietf.org>; Wed, 30 Mar 2011 13:16:07 -0700 (PDT)
Received: by iye19 with SMTP id 19so1854604iye.31 for <keyassure@ietf.org>; Wed, 30 Mar 2011 13:17:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.43.62.10 with SMTP id wy10mr1671207icb.37.1301516267070; Wed, 30 Mar 2011 13:17:47 -0700 (PDT)
Received: by 10.42.217.2 with HTTP; Wed, 30 Mar 2011 13:17:47 -0700 (PDT)
In-Reply-To: <DF4DAFFC-90DC-4AF3-88F8-9C19D39E2965@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>
Date: Wed, 30 Mar 2011 22:17:47 +0200
Message-ID: <AANLkTimbPj3iTofAo5ic7E=LS3ZtXyO5Gq=yR8fzB08d@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
To: Jay Daley <jay@nzrs.net.nz>
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 20:16:08 -0000

On Wed, Mar 30, 2011 at 10:06 PM, Jay Daley <jay@nzrs.net.nz> wrote:
>
> On 31/03/2011, at 8:32 AM, Richard L. Barnes wrote:
>
>>>>>>>> "RLB" == Richard L Barnes <rbarnes@bbn.com> writes:
>>>
>>> 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?

-Ekr