Re: [DNSOP] DLVs and ITAR

Jim Reid <jim@rfc1035.com> Fri, 11 September 2009 11:19 UTC

Return-Path: <jim@rfc1035.com>
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 03CFD3A6819 for <dnsop@core3.amsl.com>; Fri, 11 Sep 2009 04:19:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[AWL=0.852, 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 CuW0xm9bb3hp for <dnsop@core3.amsl.com>; Fri, 11 Sep 2009 04:19:46 -0700 (PDT)
Received: from hutch.rfc1035.com (hutch.rfc1035.com [195.54.233.70]) by core3.amsl.com (Postfix) with ESMTP id F346E28C10D for <dnsop@ietf.org>; Fri, 11 Sep 2009 04:19:45 -0700 (PDT)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by hutch.rfc1035.com (Postfix) with ESMTP id AE0FB1542060; Fri, 11 Sep 2009 12:20:19 +0100 (BST)
Message-Id: <196D62EA-0561-431A-879D-21F8AE4520AB@rfc1035.com>
From: Jim Reid <jim@rfc1035.com>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
In-Reply-To: <20090911094858.GA19094@nic.fr>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 11 Sep 2009 12:20:19 +0100
References: <alpine.LFD.1.10.0909081307090.9233@newtla.xelerance.com> <68F05A6E-256D-4C61-B03D-82E9E949349F@virtualized.org> <a06240800c6cc563a4381@[10.31.200.192]> <4AE266E3-E9ED-48D4-BEEE-41FB5A547392@virtualized.org> <a06240801c6cc67e5678b@[10.31.200.192]> <F6A9960F-44A8-4B97-A353-10B3578BA08E@virtualized.org> <a0624080ac6ceff5a54fd@[10.31.200.192]> <A4DC1D4D-3CC5-4BB7-A724-72BEBD0EA321@virtualized.org> <alpine.LFD.1.10.0909101705260.28494@newtla.xelerance.com> <58B0810F-29BD-4897-8E5A-46030F3417BD@rfc1035.com> <20090911094858.GA19094@nic.fr>
X-Mailer: Apple Mail (2.936)
Cc: IETF DNSOP WG <dnsop@ietf.org>
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: Fri, 11 Sep 2009 11:19:47 -0000

On 11 Sep 2009, at 10:48, Stephane Bortzmeyer wrote:

>> Now please suggest how someone can perform that due diligence in
>> circumstances where there are unknown (to them) actors
>
> If dlv.isc.org is an unknown actor to a DNSSEC-signed TLD, they indeed
> have a big problem!

Stephane, you are picking nits instead of addressing the points I made.
These focus on the fact that there are informal undocumented  
arrangements around the operation of a DLV registry, how and where  
that registry gets its keying material, how that registry publishes  
the info, what its operating practices and service commitments are,  
how others use that DLV registry for validation, what problem  
reporting and escalation procedures are available, etc, etc. These are  
the unknown actors I was referring to.

It appears there was no procedure for .pr to give ISC a heads-up about  
the key rollover. Or for ISC to nudge .pr about the problem caused by  
the changed key. That worries me. It should worry you too.

At one level this is no big deal in the context of minimal DNSSEC  
deployment and only some fraction of that being dependent on  
dlv.isc.org. However we are talking about something that affects core  
Internet infrastructure, namely a TLD. IMO, more care is needed. If  
the Internet people don't do that, there is a strong possibility their  
toys will one day get taken away because governments will decide they  
have intervene to impose order on something that appears to them to be  
(a) important; (b) unsatisfactorily supervised.

> Can you blame DLV, ISC or an unknown actor for that?

I am not blaming anyone or seeking to apportion blame. I'm simply  
pointing out that it's not wise for the operation of things like DLV  
to be based on unstated assumptions and goodwill best efforts (however  
noble these things are) instead of documented processes/procedures.

> Currently, almost no one (outside of this mailing list) uses
> DNSSEC. Yet, you say that there are people in this very small
> community that are not aware of dlv.isc.org and not aware that it
> mirrors ITAR? Come on.

No I'm not saying that. I am saying that it is not wise to work from  
assumption (correct or otherwise) that dlv.isc.org is the only DLV in  
town.
If someone claims there is no other DLV, then the onus on them is to  
prove that.