Subject: Last Call comment on draft-weiler-dnssec-dlv-iana-00.txt

From: Ted Hardie <[email-masked]>
Date: Mon, 27 Aug 2007 11:27:29 -0700

In the IESG's last call on this document, there was a request to evaluate whether
the publication of this document is in the community's best interest and, if so,
whether it should be direction to IANA or advice to IANA on what to do if
it were to deploy a DLV.  After reading the  document, I do not believe it has
sufficient detail to be advice to IANA.  This is the meat of this very short document:

2.  IANA Considerations

   IANA is asked to create a DLV registry at dlv.dnssec.arpa targeting
   the root and containing DLV records for those TLDs and reverse zones
   delegated directly by IANA that ask to have DLV records published for
   their own zones.

   IANA is instructed to use its own best practices for authenticating
   zone operators' requests to insert, modify, and delete DLV entries.

   This DLV registry MUST itself be signed with DNSSEC.

   To be clear, IANA is only being asked to publish DLV records for top
   level domains and reverse zones delegated directly from IANA, thereby
   taking advantage of the IANA's existing relationships with the these
   zone operations and established procedures for authenticating
   requests from these zone operators.

The other three numbered sections are the introduction, the security
considerations (which state it inherits them from weiler-dnssec-dlv),
and the references.  As advice goes, it isn't much.  It is also pretty
clearly a request to IANA to set up a particular DLV, and I do not
see how the IESG can treat it as

     (b)  These are the things that IANA would need to do to
           implement DLV, and IANA should follow them if DLV is
           deployed at some time in the future.

without essentially rejecting it and indicating to the author that
a re-write of a specific form would get sponsorship.  Even in that
case, though, I believe that a re-write would need a new last call,
since it would have to be significantly different from this
document to be worth it.
	To take a single example of what might be advice in such
a document, draft-arends-dnsext-dlvptr-00.txt proposes an extension
to the DLV mechanism that allows a zone holder to enter a record
naming which DLV is the repository of choice.  If draft-arends-dnsext-dlvptr-00.txt is accepted, then it might be
reasonable to advise IANA, should it decide to set up a DLV, to
ensure that the salient dlvptr records point to its DLV.  Of course,
this would be useful advice to anyone setting up a DLV, and the
advice would likely need to be updated as new mechanisms are added
and experience with DLVs gained.  Having a working group like DNSOP
develop that over time seems like a reasonable thing to do if
we do get stuck with DLVs, but I doubt that there is sufficient
operational experience at this time to do so.
	To put this more bluntly, I think b) should be off the
table for this document.
	On the remaining question, should the IESG approve this
document as:

	  (a)  These are the things that IANA would need to do to
           implement DLV, and the IETF is in favor of IANA doing
           them.

I think even that is an inaccurate reflection of this document.
"Should the IETF instruct the IANA to set up this registry?" would
be a closer reading, at least in my opinion.  My answer to that
question is no. 
	There are two reasons for that.  The first is that I strongly
prefer a signed root, and I believe that a success in the use of
DLV at this level would distract from, rather than lead the way to,
a signed root. DLV as a success here would be difficult to get out
of the DNS system once deployed (at least if cruft in any other
aspect of the Internet is any guide), and the more "official" it
appears to be, the worse that removal process will get (at least if
I read the tea leaves right this morning). 
	The second is that these instructions essentially
force the use of at least two DLVs.  Because these instructions limit
the included zones to those in the root, the DLV created by these
will not handle any other missing links in the chains of trust.  This
has already been pointed out by Mark Andrews, relative to the ISC
DLV, but it warrants repeating:  doing this might create an ersatz
signed root (and I emphasize ersatz here), but that does not solve
the problem for zones within TLDs that are not signed.  A single
DLV is plenty bad enough; having multiple DLVs without some real
design work looks to me like a potential disaster. 
	Speaking only for myself,
				Ted Hardie

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Edward Lewis <[email-masked]>
Date: Tue, 28 Aug 2007 13:23:45 -0400

At 11:27 -0700 8/27/07, Ted Hardie wrote:

>After reading the  document, I do not believe it has
>sufficient detail to be advice to IANA.

I agree with that.  I've sent details on this privately to the 
editor, WG chair, and IESG secretary as that is mostly a matter of 
mechanics.

>be a closer reading, at least in my opinion.  My answer to that

After getting my head up out of the registry operations quicksand I 
am becoming increasingly convinced that setting up a DLV at IANA is 
the wrong step to take.

>force the use of at least two DLVs.

That's very convincing to me.  Having a second DLV operator doesn't 
benefit the public Internet enough to ask IANA to take on the extra 
role.

And yes, if there is to be DNSSEC anywhere the public Internet root 
zone ought to be signed.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Aug 2007 09:56:23 +1000

> And yes, if there is to be DNSSEC anywhere the public Internet root 

	The alternative is to direct IANA to collect, maintain and
	distribute this information to the DLV operators in the
	absence of a signed root.  This would give a trusted path
	for data entry into the general DLV trees.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Wed, 29 Aug 2007 09:01:11 -0700

>	for data entry into the general DLV trees.

I don't see why the information would be distributed only to DLV
operators.  Asking IANA to publish this data on a suitably updated
web page for the information of the community would enable
both  DLV operators to use it as well as anyone who wanted to
configure those trust anchors without DLV.  As others have put this,
a trust anchor registry outside the DNS may retain the basic
mechanisms of DNSSEC better, while allowing folks to move past the
current issues with a signed root.

The underlying issue, of course, is how many TLD operators would
publish in a trust anchor registry if it is made available; hopefully
enough to provide convincing evidence that a signed root will
be worth the operational issues around protecting the keying
material.  I'm more worried that providing this registry (whether
in DLV form or some other form) will either delay work on
signing the root or that the response will be so anemic that folks
will *assume* it would be similarly anemic in the case of signed root.

In order of priority, in other words, my personal preferences are:
sign the root, put up a trust anchor registry outside the DNS, feed
the data to external DLVs, and set up a new DLV.

			regards,
				Ted

---

From: Mark Andrews <[email-masked]>
Date: Thu, 30 Aug 2007 08:24:10 +1000

> the data to external DLVs, and set up a new DLV.

	The DLV operators only need this information up until the
	root is signed.  Once the root is signed the root's DLV will
	go in and these will be removed.

	That reminds me.  I should add a log message when we use the
	root's DLV record.  It's a indication that it is time to
	add the root keys to the configuration file.

---

From: David Conrad <[email-masked]>
Date: Wed, 29 Aug 2007 15:29:30 -0700

Mark,

> 	go in and these will be removed.

If the root gets signed and you remove the DLV stuff, won't you break  
any caching resolver that still has the DLV trust anchor configured?

Regards,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Thu, 30 Aug 2007 09:23:21 +1000

> any caching resolver that still has the DLV trust anchor configured?

	No.  Please re-read the quoted paragraph.  The root's DLV
	will be there.

	You only need DLV records where there is a missing link in the
	trust chain.  If you have "." you don't need a DLV for "se" as
	there will be a DS for "se" in the root zone.

	Mark

---

From: David Conrad <[email-masked]>
Date: Wed, 29 Aug 2007 16:43:24 -0700

Mark,

> 	No.  Please re-read the quoted paragraph.  The root's DLV

Please re-read my question.

> 	there will be a DS for "se" in the root zone.

Perhaps surprisingly, I understand this.

My question, somewhat expanded, is:

If you configure a trust anchor for "the" DLV registry and at some  
point in time in the future, that DLV registry ceases to function  
_and you have not changed the trust anchor configuration_, won't  
validation fail?

The point of this question:

If you start mucking about with production services that require  
configuration on the part of system administrators (particularly in  
the somewhat arcane world of DNSSEC trust anchors), it can become  
quite difficult to stop that production service without breaking  
stuff.  Is this a place we want to go for a temporary hack?

Thanks,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Thu, 30 Aug 2007 10:07:05 +1000

> stuff.  Is this a place we want to go for a temporary hack?

	We were well aware of that.  A minimal DLV is a signed empty
	zone.  Agressive negative caching will reduce the query
	load to 1 query per neg ttl.  ~1 query every 3 hours with
	current defaults.

	Once you are in the DLV registry business you are in it for
	the long haul.  I expect it would take years to taper off.

	ISC also has a mailing list to inform people of roll overs
	on the DLV trust anchor.  This same list can be used to
	inform people that the DLV registry is shutting down
	(going to minimial state).

	If one wants to force the issue one lets the RRSIG expire
	which will break resolution for anything for which there is
	not a trust chain from a alternate trust anchor.

	Mark

---

From: John C Klensin <[email-masked]>
Date: Wed, 29 Aug 2007 21:31:31 -0400

--On Wednesday, 29 August, 2007 16:43 -0700 David Conrad
<[email-masked]> wrote:

> If you start mucking about with production services that
> require configuration on the part of system administrators
> (particularly in the somewhat arcane world of DNSSEC trust
> anchors), it can become quite difficult to stop that
> production service without breaking stuff.  Is this a place we
> want to go for a temporary hack?

David,

Are you prepared to answer the question as to when the plan for
getting the root signed as originally intended (whatever that
plan now is) is going to be executed?  

To an outsider with no particular knowledge of what is going on,
the impression is that actual root-signing is receding at
approximately one month per month, if not a little more quickly.
If that were in fact the trend, and it were to continue, then
concerns about transition from a DLV-based mechanism to a signed
root would be largely irrelevant.  

Conversely, if there were a definite plan for getting the root
signed within, say, the next few months, then it seems to me
that even discussing formalizing DLV mechanisms for the root by
having IANA create a new registry is a waste of time.

On the other hand, if there is no realistic plan and schedule,
and you don't like Sam's idea, do you have constructive
suggestions as to how it can be made acceptable?  

I do not believe that "we should just wait until the root is
signed but are not able to say anything specific about when that
might be" is a useful response at this point.  It might have
been a plausible position a year ago but, by now,...

      john

---

From: David Conrad <[email-masked]>
Date: Wed, 29 Aug 2007 18:55:02 -0700

John,

> plan now is) is going to be executed?

I have no idea what was 'originally intended', so it is difficult for  
me to answer.

I could answer and say:

% dig @ns.iana.org . axfr

and/or

https://ns.iana.org/dnssec/status.html

but I don't think that is the answer you're looking for.  I suspect  
the question you mean to ask is when will a signed root zone be  
published and propagated to the existing set of root servers.   
Unfortunately, since IANA is not in control of the publication  
process, I can't answer that particular question.

Regards,
-drc

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 30 Aug 2007 05:04:33 -0700

I think that some folk besides myself have to do some wargaming to consider what the political consequences of signing the root might be.

Consider that this is an infrastructure which needs to be robust over a timescale of several decades if not centuries. Consider also the likelihood that whoever is in charge of the root might perform an action that some party might consider a defection over such an extended timescale.

For example, a small but vocal group of voters in the western southern peninsular of state A consider themselves to be political exiles from state B, an island in the vicinity of the peninsular. State A has a particular position of influence over the root and said voters lobby for the exclusion of state B.

If such a thing were to happen today the result would be a temporary fracture of the root followed by the rapid emergence of an alternative root structure that was not subject to abusive influence from state A. The parties have authority but not power. If the root is signed by a unitary entity, that entity has absolute power. A defection cannot be countered by a fracture of the root.

Today scope for defection is kept in balance by the lack of security. The root is ultimately defined by the location to which a particular network provider directs UDP packets with the root server IP address. After signing the root will be defined by the knowledge of the private key corresponding to the widely distributed embedded public key.

Consider the fact that Europe is currently planning to duplicate the GPS satelite system at a cost of several billion dollars despite the fact that the sole point in doing so is to prevent a similar defection on the part of the US. The idea that control of the DNS root will not be subjected to even more considerable geo-political pressure is naïve. In 1995 deployment could have taken place without attracting undue attention, that is not the case today.

So no, I don't think that there will be a unitary signer. The architecture is inherently flawed. Rather than have a single party sign the root we should probably look to a situation where there are multiple signer entities.

> -----Original Message-----
> From: John C Klensin [mailto:[email-masked]] 
> Sent: Wednesday, August 29, 2007 9:32 PM
> To: David Conrad; Mark Andrews
> Cc: IETF-Discussion; [email-masked]
> Subject: Re: Last Call comment on draft-weiler-dnssec-dlv-iana-00.txt
> 
> 
> 
> Are you prepared to answer the question as to when the plan 
> for getting the root signed as originally intended (whatever 
> that plan now is) is going to be executed?  
> 
> To an outsider with no particular knowledge of what is going 
> on, the impression is that actual root-signing is receding at 
> concerns about transition from a DLV-based mechanism to a 
> signed root would be largely irrelevant.  
> 
> Conversely, if there were a definite plan for getting the 
> root signed within, say, the next few months, then it seems 
> to me that even discussing formalizing DLV mechanisms for the 
> root by having IANA create a new registry is a waste of time.
> 
> On the other hand, if there is no realistic plan and 
> schedule, and you don't like Sam's idea, do you have 
> constructive suggestions as to how it can be made acceptable?  
> 
> signed but are not able to say anything specific about when 
> that might be" is a useful response at this point.  It might 
> have been a plausible position a year ago but, by now,...
> 
>       john
> 
> 
> 
> 
>