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

"Stephan Lagerholm" <stephan.lagerholm@secure64.com> Fri, 11 March 2011 01:53 UTC

Return-Path: <stephan.lagerholm@secure64.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 9CBBC3A67E3 for <dnsext@core3.amsl.com>; Thu, 10 Mar 2011 17:53:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level:
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 mIV+0I75KxjT for <dnsext@core3.amsl.com>; Thu, 10 Mar 2011 17:53:51 -0800 (PST)
Received: from zimbra.secure64.com (unknown [64.92.221.189]) by core3.amsl.com (Postfix) with ESMTP id 851C83A67FF for <dnsext@ietf.org>; Thu, 10 Mar 2011 17:53:51 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id 7358EB8386; Thu, 10 Mar 2011 18:48:49 -0700 (MST)
X-Virus-Scanned: amavisd-new at secure64.com
Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IjT0Rr7s33P; Thu, 10 Mar 2011 18:48:47 -0700 (MST)
Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id 336F3B8312; Thu, 10 Mar 2011 18:48:47 -0700 (MST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1299808127; bh=tbUXc+Sx/6pXdk9tAZ8p/5ci+JuqAHvzMhU42YBY8iU=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To:Cc; b=f6MGU8Wm/uPX0n6CIR NWyXDfhoXYvf6deWlCQ+oLhur72almbqCt+/1YuLR73feDM5Ex7J4QdfWNUj0L48ArB 4qjpWsMEECwPxCrHR7k07JqVeKsJlIaefelsnBLLwFbP1OchDQ9oUwiyKm8yuwHq+fY 2at/17fhRiU/JVaE5kw=
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 10 Mar 2011 18:48:05 -0700
Message-ID: <DD056A31A84CFC4AB501BD56D1E14BBB9CC827@exchange.secure64.com>
In-Reply-To: <4D794DF2.5030907@ogud.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [dnsext] CDS RRTYPE review - Comments period end Mar 29th
Thread-Index: AcvfcArU3/tW5eqlRVmYr65X0+by8gAHhwzg
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> <4D794DF2.5030907@ogud.com>
From: "Stephan Lagerholm" <stephan.lagerholm@secure64.com>
To: "Olafur Gudmundsson" <ogud@ogud.com>
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: Fri, 11 Mar 2011 01:53:52 -0000

On Thursday, March 10, 2011 4:17 PM Olafur Gudmundsson wrote:
>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,
Yes, the keytag would change when a key went from Embryonic to KSK, just
like it is doing for RFC5011 revoked (flag 385) keys. The parent would
have to take that into accont when creating the DS record.

>unless validators know how to handle the flag change.
This embryonic key would not be used to sign anything, so validators
would not be affected.

>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 ......
It is not wasted space, RFC5011 is using it. There are programs such as
autotrust that relies on it, we use it to signal what keys are SEP keys,
etc... 

RFC5011 is using it to signal that a key is "dead". Why can we not use
another flag to signal that a key is about to get "born" (prior to the
DS is being published at the parent)?

/S