Re: [dnsext] Clarifying the mandatory algorithm rules

Edward Lewis <Ed.Lewis@neustar.biz> Fri, 10 December 2010 14:05 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 55F403A6B07 for <dnsext@core3.amsl.com>; Fri, 10 Dec 2010 06:05:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.049
X-Spam-Level:
X-Spam-Status: No, score=-102.049 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 hzVto5NSOGRq for <dnsext@core3.amsl.com>; Fri, 10 Dec 2010 06:04:58 -0800 (PST)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 84F183A6AE8 for <dnsext@ietf.org>; Fri, 10 Dec 2010 06:04:57 -0800 (PST)
Received: from sbaz2-lt61.cis.neustar.com (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id oBAE6JiB000935; Fri, 10 Dec 2010 09:06:19 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz)
Received: from [10.31.200.119] by sbaz2-lt61.cis.neustar.com (PGP Universal service); Fri, 10 Dec 2010 09:06:26 -0500
X-PGP-Universal: processed; by sbaz2-lt61.cis.neustar.com on Fri, 10 Dec 2010 09:06:26 -0500
Mime-Version: 1.0
Message-Id: <a06240801c927dd8e7f1b@[10.31.200.119]>
In-Reply-To: <AANLkTimdtUXHrEw5-YYFDsg=24Zff31PDq63k968Rty=@mail.gmail.com>
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> <a06240800c9268ae26e12@192.168.1.104> <4D00F385.4010405@nlnetlabs.nl> <a06240801c926a690eaef@10.31.200.118> <4D01EE19.3060006@nlnetlabs.nl> <AANLkTimdtUXHrEw5-YYFDsg=24Zff31PDq63k968Rty=@mail.gmail.com>
Date: Fri, 10 Dec 2010 09:06:15 -0500
To: Brian Dickson <brian.peter.dickson@gmail.com>
From: Edward Lewis <Ed.Lewis@neustar.biz>
Content-Type: multipart/alternative; boundary="============_-920132516==_ma============"
X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4
Cc: Edward Lewis <Ed.Lewis@neustar.biz>, 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: Fri, 10 Dec 2010 14:05:00 -0000

At 8:30 -0400 12/10/10, Brian Dickson wrote:

>One is, whether all signatures are of equal importance.
>
>I'd say, SEP-related signatures (DS signatures, DNSKEY signatures) are much
>more critical, and should receive maximum protection, performance
>notwithstanding.

RFC 4034, section 2.1.1 says this:

# Bit 15 of the Flags field is the Secure Entry Point flag, described in
# [RFC3757].  If bit 15 has value 1, then the DNSKEY record holds a key
# intended for use as a secure entry point.  This flag is only zone signing
# or debugging software as to the intended use of this DNSKEY record;
# validators MUST NOT alter their behavior during the signature validation
# process in any way based on the setting of this bit.

All signatures are equal.

>I'd also say,  the fewer labels there are, the more important, for the
>same or similar reasoning.  The higher up the food chain, the bigger the
>target painted on the zone.

An attack to "steal" from example.co.tld. will be more effective if 
just that is "taken out" than if "tld." is taken out.  Why?  Who do 
you think is better defended?  How many will "fight back" if the 
attack goes to tld's infrastructure?

>Should this be addressed? If so, how?

I've already spent more time on this theoretical topic than I will 
ever spend on it in reality.

Can someone could actually demonstrate/deliver two RRSets for a 
name/class/type that validated against the same signature.  Even for 
RSA/MD5.  (Yes, I know MD5 is "broken" but every case I've heard of 
involves large, unstructured data.  Within the constraints of the 
DNS/DNSSEC protocol elements, can it be done?)

The restriction to the same owner/class/type is because the forgery 
would have to be tied to the question asked, RFC 2181 considerations. 
I'd be curious what is the minimum number of RR's needed in the 
forged set.  (Note - if the original set has one A record, the 
forgery can have more, many more.  If the minimum needed is absurdly 
high, then we can discount the odds that the forged set would 
accepted.)

(Wish we had put the RR's in set count in the RRSIG.)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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?