Re: [DNSOP] DLVs and ITAR
Edward Lewis <Ed.Lewis@neustar.biz> Mon, 14 September 2009 19:08 UTC
Return-Path: <Ed.Lewis@neustar.biz>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B34923A6843 for <dnsop@core3.amsl.com>; Mon, 14 Sep 2009 12:08:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[AWL=0.478, 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 D40LcxOiHwls for <dnsop@core3.amsl.com>; Mon, 14 Sep 2009 12:08:46 -0700 (PDT)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 9C23B3A67F1 for <dnsop@ietf.org>; Mon, 14 Sep 2009 12:08:46 -0700 (PDT)
Received: from [10.31.200.153] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n8EJ9SYE005205; Mon, 14 Sep 2009 15:09:29 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz)
Mime-Version: 1.0
Message-Id: <a06240800c6d44242ff9b@[10.31.200.153]>
In-Reply-To: <19689600-7E8E-425F-8849-4AEB9DB38AC3@verisign.com>
References: <C6D3B6D8.15D4D%kim.davies@icann.org> <19689600-7E8E-425F-8849-4AEB9DB38AC3@verisign.com>
Date: Mon, 14 Sep 2009 15:07:41 -0400
To: IETF DNSOP WG <dnsop@ietf.org>
From: Edward Lewis <Ed.Lewis@neustar.biz>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20
Cc: ed.lewis@neustar.biz
Subject: Re: [DNSOP] DLVs and ITAR
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Sep 2009 19:08:47 -0000
At 14:45 -0400 9/14/09, David Blacka wrote: >I think it works to simply say this: > > * The ITAR should be checked for changes once per 24 hour period. > >Then: > > * consumers (e.g., dlv.isc.org, me) will know to check at least >once per day; > * TLD operators would know to pre-publish the new DS at least 24 hours > before doing the KSK roll. Plus an allowance for TTLs. It's a bit more complicated I think, unless I missed a fine point in the message. To nit pick: "TLD operators would know to pre-publish the new DS" is incorrect per se - the DS set for a zone is authoritative at the parent. When I want to change a SEP, first I plan to have it in my DNSKEY set for a long enough period to satisfy at least RFC 5011 and the time it takes for all caches to time out all DNSKEY set versions prior to the new SEP-to-be. Next I add the new SEP signature to the DNSKEY set and ask the parent to change the DS record in my DS RRSet. Change means take out the old and put in the new (per algorithm/etc.). I don't remove anything at this point. I don't think the parent's TTL considerations matter because I am placing two SEP's in to play while waiting. As soon as I see the new DS record appear in the zone (and the old DS gone), I start a timer based on my TTL for the DNSKEY set. Once that timer expires I RFC5011-revoke the old SEP (and sign the whole key set with old and new SEP key). According to RFC 5011 rules I then remove the old SEP and any signature at the appropriate time. >As it is, I don't expect any TLD operator to have any idea of how >long they must pre-publish, nor any consumer to know how often to >poll IANA for any changes. Polling is suboptimal when an event is anticipated but it is a good catch all to avoid missing an event notification. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction.
- [DNSOP] .PR servfails due to wrong key in DLV Paul Wouters
- [DNSOP] Key Management and Provisioningl was Re: … Edward Lewis
- Re: [DNSOP] Key Management and Provisioningl was … Paul Wouters
- Re: [DNSOP] Key Management and Provisioningl was … Edward Lewis
- Re: [DNSOP] Key Management and Provisioningl was … bmanning
- Re: [DNSOP] Key Management and Provisioningl was … David Conrad
- Re: [DNSOP] Key Management and Provisioningl was … Edward Lewis
- Re: [DNSOP] Key Management and Provisioningl was … Paul Wouters
- Re: [DNSOP] Key Management and Provisioningl was … David Conrad
- Re: [DNSOP] Key Management and Provisioningl was … Edward Lewis
- [DNSOP] provisioning and OT&E for the signed root Jim Reid
- Re: [DNSOP] provisioning and OT&E for the signed … Edward Lewis
- Re: [DNSOP] Key Management and Provisioningl was … David Conrad
- Re: [DNSOP] Key Management and Provisioningl was … Edward Lewis
- Re: [DNSOP] Key Management and Provisioningl was … David Conrad
- Re: [DNSOP] Key Management and Provisioningl was … Paul Wouters
- [DNSOP] DLVs and ITAR Jim Reid
- Re: [DNSOP] DLVs and ITAR Stephane Bortzmeyer
- Re: [DNSOP] DLVs and ITAR Jim Reid
- Re: [DNSOP] DLVs and ITAR Paul Wouters
- Re: [DNSOP] DLVs and ITAR Jim Reid
- Re: [DNSOP] DLVs and ITAR Mark Andrews
- Re: [DNSOP] DLVs and ITAR Kim Davies
- Re: [DNSOP] DLVs and ITAR Kim Davies
- Re: [DNSOP] DLVs and ITAR Mark Andrews
- Re: [DNSOP] DLVs and ITAR Mark Andrews
- Re: [DNSOP] DLVs and ITAR Kim Davies
- Re: [DNSOP] DLVs and ITAR joao damas
- Re: [DNSOP] DLVs and ITAR Kim Davies
- Re: [DNSOP] DLVs and ITAR David Blacka
- Re: [DNSOP] DLVs and ITAR Thierry Moreau
- Re: [DNSOP] DLVs and ITAR Edward Lewis
- Re: [DNSOP] DLVs and ITAR Mark Andrews
- Re: [DNSOP] DLVs and ITAR Holger Zuleger
- Re: [DNSOP] DLVs and ITAR Mark Andrews
- Re: [DNSOP] DLVs and ITAR Mark Andrews
- Re: [DNSOP] Key Management and Provisioningl was … Roy Arends
- Re: [DNSOP] Key Management and Provisioningl was … joao damas
- Re: [DNSOP] Key Management and Provisioningl was … Roy Arends
- Re: [DNSOP] Key Management and Provisioningl was … joao damas
- Re: [DNSOP] Key Management and Provisioningl was … Roy Arends
- Re: [DNSOP] Key Management and Provisioningl was … joao damas
- Re: [DNSOP] Key Management and Provisioningl was … Joe Abley
- Re: [DNSOP] Key Management and Provisioningl was … Florian Weimer
- Re: [DNSOP] Key Management and Provisioningl was … Roy Arends
- Re: [DNSOP] Key Management and Provisioningl was … Florian Weimer
- Re: [DNSOP] Key Management and Provisioningl was … Mark Andrews
- Re: [DNSOP] Key Management and Provisioningl was … Stephane Bortzmeyer
- Re: [DNSOP] Key Management and Provisioningl was … David Conrad
- Re: [DNSOP] Key Management and Provisioningl was … Mark Andrews
- Re: [DNSOP] Key Management and Provisioningl was … Stephane Bortzmeyer
- Re: [DNSOP] Key Management and Provisioningl was … David Conrad
- Re: [DNSOP] Key Management and Provisioningl was … Mark Andrews
- Re: [DNSOP] Key Management and Provisioningl was … Roy Arends
- Re: [DNSOP] Key Management and Provisioningl was … Mark Andrews
- Re: [DNSOP] Key Management and Provisioningl was … Edward Lewis
- Re: [DNSOP] Key Management and Provisioningl was … Mark Andrews
- Re: [DNSOP] Key Management and Provisioningl was … Mark Andrews
- Re: [DNSOP] Key Management and Provisioningl was … Mark Andrews
- Re: [DNSOP] Key Management and Provisioningl was … Chris Thompson
- Re: [DNSOP] Key Management and Provisioningl was … Kim Davies
- Re: [DNSOP] Key Management and Provisioningl was … Mark Andrews
- Re: [DNSOP] Key Management and Provisioningl was … Kim Davies
- Re: [DNSOP] Key Management and Provisioningl was … Mark Andrews
- Re: [DNSOP] Key Management and Provisioningl was … Michael Graff
- Re: [DNSOP] Key Management and Provisioningl was … Chris Thompson
- Re: [DNSOP] Key Management and Provisioningl was … Michael Graff
- Re: [DNSOP] Key Management and Provisioningl was … Chris Thompson
- Re: [DNSOP] Key Management and Provisioningl was … Edward Lewis
- Re: [DNSOP] Key Management and Provisioningl was … Mark Andrews
- Re: [DNSOP] .PR servfails due to wrong key in DLV David Conrad
- Re: [DNSOP] .PR servfails due to wrong key in DLV Stephane Bortzmeyer
- Re: [DNSOP] .PR servfails due to wrong key in DLV Mark Andrews