Re: [dnsext] Clarifying the mandatory algorithm rules

Edward Lewis <Ed.Lewis@neustar.biz> Thu, 09 December 2010 13:43 UTC

Return-Path: <Ed.Lewis@neustar.biz>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0396928C102 for <dnsext@core3.amsl.com>; Thu, 9 Dec 2010 05:43:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.83
X-Spam-Level:
X-Spam-Status: No, score=-101.83 tagged_above=-999 required=5 tests=[AWL=0.769, 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 8UBnrDWyLF+E for <dnsext@core3.amsl.com>; Thu, 9 Dec 2010 05:43:03 -0800 (PST)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id E5FF428C0FF for <dnsext@ietf.org>; Thu, 9 Dec 2010 05:43:02 -0800 (PST)
Received: from ames-lt510.cis.neustar.com (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id oB9DiNA6090664; Thu, 9 Dec 2010 08:44:24 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz)
Received: from [10.31.200.118] by ames-lt510.cis.neustar.com (PGP Universal service); Thu, 09 Dec 2010 08:44:31 -0500
X-PGP-Universal: processed; by ames-lt510.cis.neustar.com on Thu, 09 Dec 2010 08:44:31 -0500
Mime-Version: 1.0
Message-Id: <a06240800c9268ae26e12@[192.168.1.104]>
In-Reply-To: <4D00A86D.1040304@nlnetlabs.nl>
References: <alpine.BSF.2.00.1011180553250.83352@fledge.watson.org> <4CE51293.5040605@nlnetlabs.nl> <a06240801c9101620d463@[192.168.128.163]> <22284.1290447209@nsa.vix.com> <4CF4D54B.5000407@nlnetlabs.nl> <4D00A86D.1040304@nlnetlabs.nl>
Date: Thu, 09 Dec 2010 08:44:20 -0500
To: Matthijs Mekking <matthijs@NLnetLabs.nl>
From: Edward Lewis <Ed.Lewis@neustar.biz>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4
Cc: dnsext@ietf.org
Subject: Re: [dnsext] Clarifying the mandatory algorithm rules
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Dec 2010 13:43:04 -0000

At 10:59 +0100 12/9/10, Matthijs Mekking wrote:

>Although this is local policy, I also think it is bad policy for a
>validator to allow algorithm compromises and badly signed zones. Thus, I
>would go for a MUST here.

The reason it can't be a MUST is that a zone may be signed with 
algorithm 42.  If a resolver does not know algorithm 42, how can it 
determine whether the signature using algorithm 42 is valid or 
invalid?

Let's say a zone is signed by algorithms 5 and 7.  (A choice made 
specifically because the two algorithms have the same mathematical 
properties. ;))  What would you think if you received a set of data 
and signatures and discovered that the algorithm 5 signature 
validated the signature but the algorithm 7 signature did not.  What 
if the reason were cryptographic?  What if the reason was that the 
algorithm 7 signature had simply expired (with or without NTP 
running)?  What if the reason was that the algorithm 7 signature had 
not yet entered its effectivity period?

If you can establish a chain of trust to a data set, why withhold it 
from the application requesting it in case you find that there is 
also a signature that fails?

Assume a set of data has a legitimate signature in algorithm 5 that 
validates and you see an algorithm 7 signature that does not 
validate?  What if the cause of this was that an attacker wanted to 
perform a Denial of Service by applying an intentionally bad 
signature (which is trivial to do) to guarantee a failed chain of 
trust?  It's like allowing someone to say "don't trust the 
authorities, I'll insert some doubt so you won't use the information."

When you consider that it is far easier to insert harmful bad 
signatures than harmful bad data (because the latter requires a valid 
signature), you have to build the (or any security) protocol to be 
somewhat skeptical of it's own potentially-false positives.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Ever get the feeling that someday if you google for your own life story,
you'll find that someone has already written it and it's on sale at Amazon?