Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th

Olafur Gudmundsson <ogud@ogud.com> Thu, 10 March 2011 22:16 UTC

Return-Path: <ogud@ogud.com>
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 7B25F3A6ADE for <dnsext@core3.amsl.com>; Thu, 10 Mar 2011 14:16:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.552
X-Spam-Level:
X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 KYw98BzKtkbs for <dnsext@core3.amsl.com>; Thu, 10 Mar 2011 14:16:14 -0800 (PST)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 7465E3A6A79 for <dnsext@ietf.org>; Thu, 10 Mar 2011 14:16:14 -0800 (PST)
Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2AMHTrH058686; Thu, 10 Mar 2011 17:17:29 -0500 (EST) (envelope-from ogud@ogud.com)
Message-ID: <4D794DF2.5030907@ogud.com>
Date: Thu, 10 Mar 2011 17:17:22 -0500
From: Olafur Gudmundsson <ogud@ogud.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: Stephan Lagerholm <stephan.lagerholm@secure64.com>
References: <C99C3502.72B1%roy@nominet.org.uk> <alpine.LSU.2.00.1103082030190.5244@hermes-1.csi.cam.ac.uk><20110309133017.GA19809@odin.mars.sol><4D778C86.4020105@ogud.com> <DD056A31A84CFC4AB501BD56D1E14BBB9CC7CB@exchange.secure64.com> <3D41A425A17444EA8EEE8C78DD18D3E9@local> <DD056A31A84CFC4AB501BD56D1E14BBB9CC7FC@exchange.secure64.com>
In-Reply-To: <DD056A31A84CFC4AB501BD56D1E14BBB9CC7FC@exchange.secure64.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4
Cc: dnsext@ietf.org
Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th
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, 10 Mar 2011 22:16:15 -0000

On 10/03/2011 2:48 PM, Stephan Lagerholm wrote:
> George B and Mark A,
>
>> In either case the software that signs zones has to be updated.
>
> If adding a new flag to DNSKEY and if the software already supports the
> DNSKEY RR with arbitrary flags, then no update is needed. For example, I
> could use an old version of ISC dig and still make sense out of the
> DNSKEY record even if a new flag was added. But I had to upgrade ISC dig
> if I wanted to figure out details about the CDS record.
>
>> If the output is in text format, the generic text format of RFC3597
> section 5
>> may be used if the serving software for the master server has not been
> updated.
>
> The RDATA field would still just be a "blob". How would I for example be
> able to verify the Key Tag, Algorithm or Digest Type field unless the
> software you are using is programmed to understand that the format the
> same as for the DS record?
>
>> The software for secondary servers does not need to be updated in any
> case,
>> assuming it implements RFC3597 ( that is it can handle unknown types ),
>> which is of course the case for all mainstream implementations.
>
> Agreed, I'm taking about software that interacts with humans and try to
> display something meaningful for them (provisioning system, IPAM,
> debugging tools, etc)
>
> (For the record, I'm positive to this draft other than using a new RR
> type. I would rather like to see an "embryonic" flag to the DNSKEY
> similar to what the revoked flag is doing for old keys is RFC5011)
>
> /S
>
>
>

Stephan,
there is a problem with using a flag as
the flag field is covered both by DNSKEY keytag calculation and DS 
digest calculation.
Thus changing the flag will "revoke" the key and/or its signatures,
unless validators know how to handle the flag change.

For all practical purposes the key flag field is a wasted space
I tried to have it killed when we did the type code rollover
(KEY ---> DNSKEY) along with the protocol field, but ......

	Olafur