Re: [dnsext] New Version Notification for draft-barton-clone-dns-labels-fun-profit-00

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> Tue, 08 March 2011 15:52 UTC

Return-Path: <nweaver@ICSI.Berkeley.EDU>
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 1ACBF3A687A for <dnsext@core3.amsl.com>; Tue, 8 Mar 2011 07:52:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.513
X-Spam-Level:
X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599]
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 Xl2cvWFn0mvv for <dnsext@core3.amsl.com>; Tue, 8 Mar 2011 07:52:20 -0800 (PST)
Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id E81A33A67AA for <dnsext@ietf.org>; Tue, 8 Mar 2011 07:52:20 -0800 (PST)
Received: from gala.icir.org (gala.ICIR.org [192.150.187.49]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 2DCD2369FE9; Tue, 8 Mar 2011 07:53:36 -0800 (PST)
References: <4D74E409.1060409@dougbarton.us> <79987316-C80C-4015-A3D3-77F8D2F33351@icsi.berkeley.edu> <4D758753.3090900@dougbarton.us>
In-Reply-To: <4D758753.3090900@dougbarton.us>
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
Message-Id: <E9EAA80C-78FF-4246-869F-CCB49A4AC1AD@ICSI.Berkeley.EDU>
Content-Transfer-Encoding: quoted-printable
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
Date: Tue, 8 Mar 2011 07:53:35 -0800
To: Doug Barton <dougb@dougbarton.us>
X-Mailer: Apple Mail (2.1082)
Cc: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>, dnsext@ietf.org
Subject: Re: [dnsext] New Version Notification for draft-barton-clone-dns-labels-fun-profit-00
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: Tue, 08 Mar 2011 15:52:22 -0000

On Mar 7, 2011, at 5:33 PM, Doug Barton wrote:
>> The more important configuration is probably the model of
>> 
>> CARNS STUB<---->  Non-CARNS Resolver<--->  CARNS Auth.
> 
> I hadn't considered the idea of making a stub CLONE-Aware, but I like it. :)

This came up in private discussion when it was clear I had a different model (resolver change) vs I can't remember who (stub change).

The result was I was convinced I was wrong:  I was convinced that Stub change is actually far more likely.  

EG, take arabic.  With a resolver change model, every resolver which has at least a few arabic clients needs to upgrade, which is effectively everyone.  But most resolvers won't substantially benefit, so why bother upgrading?

But with stub changes, ONLY those who actually benefit substantially need to change.

>> As it is far more likely that clients will upgrade (EG, as part of
>> the browser or OS) rather than resolver authorities in many cases.
>> 
>> I do not know if unknown EDNS0 options are likely to be passed from
>> the stub to the authority through the intermediary resolver,
> 
> I'm not sure what the default behavior is there, but if the actual resolver is not CLONE-Aware then sending the option wouldn't help since it wouldn't understand any CLONE RRs that it received back.

Hmmm, which again makes me think the model might need to be more like how AAAA records are handeled: Do a parallel fetch for CLONE and use the result if it arrives within X ms of the cached record you were looking for, as unknown RTYPEs (mostly) work, and when they don't, the stub should be bypassing the configured recursive resolver anyway.


>> The CLONE RR really needs to be a "canonicalization program",
>> describing a set of character/word transformations that should be
>> applied, NOT just a simple pointer.[1]
> 
> How would you represent the canonicalization?

Basically, it boils down to the following requirement space for DNSSEC to work with CLONE-type operations:

1:  If the input space is small, DNSSEC can be done statically.


2:  If the input space is huge, but, IN PRACTICE, the used input space is small, dynamic signatures and caching works without introducing single-points-of-failure in practice.  [1]

It can be new RRs (CLONE), it can be abusing existing RRs (0-TTL CNAME/DNAME), but dynamic DNSSEC signatures are REQUIRED unless you use new RRs which support many-to-one mappings.


3:  If the input space is huge and, in practice, the used input space is large, the solution space is either:

a)  Dynamic signatures which ARE a single-point-of-failure and DOS target

b)  New RRs which represents MANY-to-one mappings, where only a few such RRs can cover the entire space for a given name (enables static signatures)

c)  "Paint the mountain pink and slap an SEP ('Somebody Else's Problem) field on it".  Its far better than having to try to explain the suspicious new moon...


This is why I believe that a CLONE type record needs to be a 'canonicalization program' or a pointer to how to do the canonicalization (namely, a pointer to a program), because in order for DNSSEC to work without static signatures in case 2 or 3 (which is, I believe, what is to be addressed), CLONE records need to be many-to-one mappings and not one-to-one mappings, and the only way to do truly generic many-to-one mappings is to sign a program that the recipient can use to compute the mapping.


Which is, admittedly, a MUCH harder problem but necessary if dynamic signatures are off the table (as some in this group have advocated).





[1] Dynamically generated signatures, however, are NOT a single point of failure NOR a DOS opportunity IF the 'in practice' canonicalization space is small.  This can be measured by applying the canonicalization transformation to a large written corpus (eg, a target-language email corpus).