Re: [dnsext] Clarifying the mandatory algorithm rules

Edward Lewis <Ed.Lewis@neustar.biz> Mon, 14 March 2011 13:40 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 41EC23A6D18 for <dnsext@core3.amsl.com>; Mon, 14 Mar 2011 06:40:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.278
X-Spam-Level:
X-Spam-Status: No, score=-102.278 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, 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 QAcFs5L5CvsQ for <dnsext@core3.amsl.com>; Mon, 14 Mar 2011 06:40:30 -0700 (PDT)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 4A7A33A6958 for <dnsext@ietf.org>; Mon, 14 Mar 2011 06:40:30 -0700 (PDT)
Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2EDflig020866; Mon, 14 Mar 2011 09:41:47 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz)
Received: from [10.31.200.110] by Work-Laptop-2.local (PGP Universal service); Mon, 14 Mar 2011 09:41:53 -0400
X-PGP-Universal: processed; by Work-Laptop-2.local on Mon, 14 Mar 2011 09:41:53 -0400
Mime-Version: 1.0
Message-Id: <a06240800c9a3c90e2f16@[10.31.200.110]>
In-Reply-To: <alpine.BSF.2.00.1103140901170.99213@fledge.watson.org>
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><alpine.BSF.2.00.1103100812260.60284@fledge .watson.org> <20110310223438.978E9C0E902@drugs.dv.isc.org> <4D79DDFA.3010006@nlnetlabs.nl> <alpine.BSF.2.00.1103140901170.99213@fledge.watson.org>
Date: Mon, 14 Mar 2011 09:41:41 -0400
To: dnsext@ietf.org
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: ed.lewis@neustar.biz
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: Mon, 14 Mar 2011 13:40:31 -0000

At 9:10 -0400 3/14/11, Samuel Weiler wrote:

>then presumably we're also changing what it means to be a "properly signed
>zone".  What's the new definition?  And why that change?

Although Sam wrote this, I'm not assuming this is his opinion.

To a validator, whether or not a zone is properly signed should be 
immaterial.  A validator's concern is whether a set of data is 
properly authenticated.

The switch from "signed" to "authenticated" is on purpose, yet 
subtle.  The reason I switched is to switch from a voice of "supply 
side" to "demand side."

As a supply side'r, I'm concerned with how something is accomplished. 
Signing is one basic unit in DNSSEC.  And making sure the zone is 
properly signed is my goal.  "Properly" is relative to the 
specifications, the role of the specs is to set up expectations on 
the other side.

As a demand side'r, I'm concerned with what has been done. 
Authenticating the data is what I am achieving.  Authenticating 
involves first setting the expectation of whether I get the data I 
need (the RRSIG) and then seeing if the expectation is met.

What I am cautioning against is the degree to which a demand side'r 
goes to determine expectations.  A paranoid demand side'r almost 
looks for excuses to declare data unauthentic, and that's bad.  A 
lazy demand side'r avoids looking as much as possible, and that's 
just as bad.  A happy medium is needed.

A happy medium to me is one where the focus is goal-oriented.  If the 
data has a valid signature and I can use a chain of keys up to a 
trusted anchor, then I declare victory.  There's no security problem 
with that.

So, when it comes to validation, we should not even have a definition 
of "properly signed zone."  That is in the domain of the signer.

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

Me to infant son: "Waah! Waah! Is that all you can say?  Waah?"
Son: "Waah!"