Re: [DNSOP] Key Management and Provisioningl was Re: .PR ...

Mark Andrews <marka@isc.org> Sat, 12 September 2009 02:17 UTC

Return-Path: <marka@isc.org>
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 B49A83A69AF for <dnsop@core3.amsl.com>; Fri, 11 Sep 2009 19:17:01 -0700 (PDT)
X-Quarantine-ID: <OlPrLqIlcz7L>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER, Duplicate header field: "Cc"
X-Spam-Flag: NO
X-Spam-Score: -2.418
X-Spam-Level:
X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 OlPrLqIlcz7L for <dnsop@core3.amsl.com>; Fri, 11 Sep 2009 19:17:00 -0700 (PDT)
Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id 4F0083A694C for <dnsop@ietf.org>; Fri, 11 Sep 2009 19:17:00 -0700 (PDT)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id B3963E601E; Sat, 12 Sep 2009 02:17:36 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n8C2HV1b085031; Sat, 12 Sep 2009 12:17:32 +1000 (EST) (envelope-from marka@drugs.dv.isc.org)
Message-Id: <200909120217.n8C2HV1b085031@drugs.dv.isc.org>
To: Roy Arends <roy@dnss.ec>
From: Mark Andrews <marka@isc.org>
References: <20090908150823.GA30391@nic.fr> <alpine.LFD.1.10.0909081148270.9233@newtla.xelerance.com> <a06240800c6cc38daf7de@[10.31.200.192]> <alpine.LFD.1.10.0909081307090.9233@newtla.xelerance.com> <68F05A6E-256D-4C61-B03D-82E9E949349F@virtualized.org> <20090908203201.GA4281@nic.fr> <89290757-1889-4CC1-9879-40115FD826B6@virtualized.org> <26B62956-FE40-4F21-9E75-49BA7C3B8C24@dnss.ec>
In-reply-to: Your message of "Fri, 11 Sep 2009 16:48:16 +0200." <26B62956-FE40-4F21-9E75-49BA7C3B8C24@dnss.ec>
Date: Sat, 12 Sep 2009 12:17:31 +1000
Sender: marka@isc.org
Cc: tech@nic.pr, dnsop@ietf.org, David Conrad <drc@virtualized.org>
Subject: Re: [DNSOP] Key Management and Provisioningl was Re: .PR ...
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: Sat, 12 Sep 2009 02:17:01 -0000

In message <26B62956-FE40-4F21-9E75-49BA7C3B8C24@dnss.ec>, Roy Arends writes:
> On Sep 10, 2009, at 9:17 PM, David Conrad wrote:
> 
> > The issue is that ISC harvests data from the ITAR and they didn't  
> > synch the change submitted by PR to the ITAR.
> 
> Indeed.
> 
> DLV registries that choose to sync with ITARs should do that  
> regularly. Synching once a week is ridiculously low.
> 
> Why should the operators of PR care about this DLV? What if some other  
> DLV decides to synch with itar once a month? How does PR or some other  
> registry with keys in ITAR know which DLV synch's how often with what  
> TAR?
> 
> The problem is DLV. Not ITAR. Not PR.

Actually there is blame all round.

PR for not performing a key rollover correctly.  They still havn't
updated their own web site <http://dnssec.nic.pr/serverconf.php> so
there will be people who haven't been informed yet.

	trusted-keys {
	"pr." 256 3 5
	"BQEAAAABvS8Q64q8v62DW3y4EtUmsHr0dpU9Mizo63NXFMlEA4UaO88s B5il79Mb
	J0dzmRZ7M+j/E5pVSTTazJsK6LMnncBF3bwMWo4/nVVB0d9E 6CsClsJFU+A0a8kWI
	Z+aXuqUHO7QZ88qG7cwLbTNwHeo1X+ArvXgXmU6 OaemL3v5+eU=";

	"pr." 257 3 5 
	"AwEAAc6SkFSHw00wJFUWd1Td/efsxhfX+UTrxrzqQXNuZ8Qj2PiP6p/m BxysJt06
	XgSCB41CPhkgvgqrtdaJ/hXKG81xNXUcGfqvV9wYMJnN+oBB /lLaQU/39fWaNc4fB
	GiRI2dNDVKPry2YX6y04YrEGRM+wf6HWHVdW1Js xuMuDOSr";
	};

ITAR for not publishing a polling interval.   I would recommend
that it be in line with the TTL that they are going to use on the
DS records.  I would expect this to be 1-2 days.

ISC for having a highish polling interval.  I've recommending that
ISC drops the poll interval down to 1 hour which is inline with the
TTL of the DLV record.

ISC needs to make sure its polling interval of the ITAR + DLV TTL
is less than the maximim ITAR polling interval so that no extra
delay is added.

Mark

> Roy
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org