Re: [dnsext] Clarifying the mandatory algorithm rules

Edward Lewis <Ed.Lewis@neustar.biz> Thu, 09 December 2010 15:48 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 65BA73A6B61 for <dnsext@core3.amsl.com>; Thu, 9 Dec 2010 07:48:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.958
X-Spam-Level:
X-Spam-Status: No, score=-101.958 tagged_above=-999 required=5 tests=[AWL=0.641, 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 Xg1N0hJI9fES for <dnsext@core3.amsl.com>; Thu, 9 Dec 2010 07:48:21 -0800 (PST)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 6404A3A6B5C for <dnsext@ietf.org>; Thu, 9 Dec 2010 07:48:21 -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 oB9FnguL091682; Thu, 9 Dec 2010 10:49:42 -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 10:49:50 -0500
X-PGP-Universal: processed; by ames-lt510.cis.neustar.com on Thu, 09 Dec 2010 10:49:50 -0500
Mime-Version: 1.0
Message-Id: <a06240801c926a690eaef@[10.31.200.118]>
In-Reply-To: <4D00F385.4010405@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> <a06240800c9268ae26e12@[192.168.1.104]> <4D00F385.4010405@nlnetlabs.nl>
Date: Thu, 09 Dec 2010 10:47:07 -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 15:48:22 -0000

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

>Because the zone operator specifically wants to be protected against
>algorithm compromises and does that by listing more than one algorithm
>in the DS RRset.

DNSSEC is not designed to protect the zone operator, it is designed 
to protect the relying party.  Listing more than one algorithm is 
done to reach a wider audience, it does not enhance the security as 
far as the zone operator is concerned.

In the experimentation period before the first RFCs were produced 
(RFC 2052 being the first milestone) we played with the notion of key 
strengths.  (Keys, not algorithms because back then we only had the 
unencumbered DSA and the copyrighted RSA available.)  Trying to 
enhance the concept of DNSSEC by using the notion that one algorithm 
is better or one key is better than another failed time and time 
again.  When there's a weak link involved you can't overcome it.

What if your zone is signed with algorithm 42?  You might be more 
strongly signed than anyone else.  But what if you are delegated from 
a parent using RSA/MD5?  Your strengths are negated and if algorithm 
42 is not widely deployed you are even seen as unsigned to the masses.

So, so what if I say DNSSEC is not there to protect the zone 
operator.  Why does that mean that MUST is wrong?  The rationale is 
that no matter what you do, local policy is going to be followed. 
Local policy is going to prefer quick resolution of the query. 
Requiring DNSSEC to do extra or extraneous work is not constructive - 
by that I mean, once you've gotten a chain of trust why keep trying 
to find faults?  DNSSEC is not designed to be the last line of 
defense.

DNSSEC is never going to overcome weaknesses in the underlying 
cryptography.  Trying to do so is a futile quest and the relying 
party suffers.

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