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.