Subject: Re: Last Call: draft-weiler-dnssec-dlv-iana (DNSSEC Lookaside Validation (DLV) IANA Registry) to Informational RFC

From: Geoff Huston <[email-masked]>
Date: Fri, 24 Aug 2007 09:49:58 +1000

Part of the issue with IANA-instruction documents is that they fail to 
expose the considerations that have motivated the proposed action, and 
it's this lack of context during the review phase that tends to provoke 
a critical reaction.

I suspect that what the IESG is asking for is a roundabout way of a 
consensus call on the proposed instruction to IANA, not publication of 
the document. (Here I'm reading the whitespace of the IESG text, not 
their actual words!)

The question of "should it be published?" I interpret as a question of 
"should the IETF attempt to direct the IANA to create such a registry as 
a part of an IETF standards action?"

Two subsidiary questions back to the IESG:

     - given that this is not a standards action document, does
       publication of the document as informational constitute a clear
       and definitive instruction to IANA?

     - under the current division of responsibilities between the
       various bodies who claim interest in the DNS, is it the role of
       the IETF to undertake such an instruction to IANA in this DNS
       space?

There are a number of subject-oriented questions about DLV, as distinct 
from process and role issues that this proposed action also highlights:

- what key should IANA use to sign this DLV registry?

- would this key be any different than a hypothetical key that would be 
used to sign the DNS root? Why? Why Not?

- is this just an ersatz root signing mechanism? Why is this appropriate 
given that the alternative is simply a signed root zone?

- in the absence of full signing of the DNS from the root down, just how 
many DLV spots must a resolver look in? It seems that proliferation of 
DLV lookup points is no better (and arguably much worse) than the 
original problem of piecemeal DNSSEC deployment - that of key hunting.

Now I'm sure that the author of this document has answers to these and 
many more questions, as these considerations are indeed the motivation 
for the proposed action.

However, without this motivational information available, the proposed 
action appears to be one that openly admits that the intended deployment 
model of DNSSEC is now defunct, in which case one wonders whether this 
change of direction would materially alter DNSSEC's deployment 
prospects. So, in the absence of such additional material to motivate 
this instruction to IANA, I'm lead to the response to the IESG that:

1. Should this document be published?

    No - I do not see adequate rational for this instruction to IANA.

2. If so...

     N/A

regards,

   Geoff Huston

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

---

From: Mark Andrews <[email-masked]>
Date: Fri, 24 Aug 2007 10:54:41 +1000

> - what key should IANA use to sign this DLV registry?

	One IANA creates and publishes.  This is no different to
	what ISC did.
 
> used to sign the DNS root? Why? Why Not?

	In pure DNSSEC terms it can't be the root key.  The only
	way it could be the root key is if the root is signed and
	the registry was part of the root zone.
 
> given that the alternative is simply a signed root zone?
	
	This proposal is a way to move forward without waiting for
	the politics of signing the root to resolve.  This is
	the classic case of the network routing around a blockage.
	I do believe that it will eventually resolve but at glacial
	pace.

	Generally, DLV trees can work around missing chains of trust.
	This helps regardless of whether the root is signed or not.
	You need to get all infrastructure providors to sign their
	zones before DLV will become irrelevent.

> original problem of piecemeal DNSSEC deployment - that of key hunting.

	Hopefully only one.  You would use IANA's one if you want
	to see what the world would be like if the root is signed.
	You would use ISC's (or similar) if you want to work around
	missing links in the chains of trust.
 
> many more questions, as these considerations are indeed the motivation 

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

---

From: Geoff Huston <[email-masked]>
Date: Fri, 24 Aug 2007 13:17:34 +1000

> 	missing links in the chains of trust.

But that's not one - that's *two* already - and we've really not even 
begun to have fun with DLVs yet!

   Geoff

---

From: David Kessens <[email-masked]>
Date: Thu, 23 Aug 2007 22:01:12 -0700

Mark,

> I do believe that it will eventually resolve but at glacial

Or is it helping the blockage to persist as there will be less
pressure to get this issue resolved ?

As the RIPE community stated in an earlier message to ICANN, blocking
the operational deployment of IETF technology is in fact undermining
the security and stability of the Internet
(http://www.ripe.net/ripe/wg/dns/icann-root-signing.pdf) and is
thereby a very serious issue. I much prefer to have the IAB and IESG
work on encouraging ICANN to get the root signed than that they (and
IANA) spend time and resources on "temporary" workarounds.

David Kessens
---

---

From: Mark Andrews <[email-masked]>
Date: Fri, 24 Aug 2007 15:32:22 +1000

> pressure to get this issue resolved ?

	I suspect the answer to that is how many TLDs are waiting
	for there to be somewhere to send their DNSKEYS/DS records?
	IANA, I believe, would be the collector in either case.  This
	would, if nothing else, get that piece in place.

---

From: David Conrad <[email-masked]>
Date: Thu, 23 Aug 2007 22:47:57 -0700

% dig @ns.iana.org . axfr | grep "IN  DS" | awk '{ print $1 }' | sort  
| uniq

:-)

Regards,
-drc

---

From: Thomas Narten <[email-masked]>
Date: Fri, 24 Aug 2007 09:27:47 -0400

> given that the alternative is simply a signed root zone?

For me, this is a key question. It seems to me that the _only_ reason
DLV (and this IANA action) is needed is to get around the fact that
signing of DNSSEC zones is lagging. DLV and the registry is an attempt
to get around that.

Thus, it strikes me that this is embracing and extending DNSSEC. That
might be OK, if the relevent DNS WGs agreed that DNSSEC needed such
"help". But, as far as I can tell, the relevent DNS WGs have not
embraced this approach.

I would be troubled to see this go forward (with _any_ sort of IETF
seal of approval), without the consensus of the relevant IETF DNS
community behind it.

Thomas

---

From: Edward Lewis <[email-masked]>
Date: Fri, 24 Aug 2007 11:41:28 -0400

I've sent private comments on the draft already, as I see the draft 
as an under specification of what is required to operate a registry 
(a registry is not just DNS).  None of those comments are significant 
enough for a broad audience, just requesting better descriptions of 
the work needed to perform the service.

>>  given that the alternative is simply a signed root zone?

It is appropriate because this is a technical solution from a 
technical organization to the non-technical obstacles to a signed 
public Internet root zone.  The alternatives for the IETF are to do 
nothing or try to make an appeal on a non-technical basis.  But...

>"help". But, as far as I can tell, the relevent DNS WGs have not

...DNSSEC's lack of adoption may be because of the tradeoff of cost 
of deployment and benefit not merely an unsigned public Internet 
root.  DLV isn't an approach that will guarantee to break open the 
flood gates of DNSSEC adoption.

>seal of approval), without the consensus of the relevant IETF DNS

Getting the public Internet root signed is more significant to me. 
If that root zone isn't signed, I'd take it as a sign that DNSSEC is 
not worth the cost.  The public Internet root zone is a role model. 
If the case for DNSSEC can't be made "up there" then the case might 
not be made "down here."  I think that the non-technical approach, 
albeit not the IETF's strength, is more appropriate than further 
tinkering with the protocol and implementations.  That's because I 
don't like the implications of the tinkering I see needed to make 
this work.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.

---

From: John C Klensin <[email-masked]>
Date: Fri, 24 Aug 2007 11:53:55 -0400

--On Friday, 24 August, 2007 09:27 -0400 Thomas Narten
<[email-masked]> wrote:

>> - is this just an ersatz root signing mechanism? Why is this
>> appropriate  given that the alternative is simply a signed
>> root zone?
> 
> For me, this is a key question. It seems to me that the _only_
> reason DLV (and this IANA action) is needed is to get around
> the fact that signing of DNSSEC zones is lagging. DLV and the
> registry is an attempt to get around that.
> 
> Thus, it strikes me that this is embracing and extending
> DNSSEC. That might be OK, if the relevent DNS WGs agreed that
> DNSSEC needed such "help". But, as far as I can tell, the
> relevent DNS WGs have not embraced this approach.

Thomas, 

Let me try a different perspective.  It seems to me that there
are two separate components of a document like this (and Sam's
base DLV spec).  It also seems to me that, in separating
draft-weiler-dnssec-dlv from
draft-weiler-dnssec-dlv-iana-00.txt, Sam (perhaps with a little
prompting in earlier rounds) has adequately performed the split
into two separate documents.

For the base DLV spec, I think there are reasonable questions
about whether a reasonable person would want to do something
like this and about whether, if one were going to do it (whether
it would be reasonable or not), this particular specification is
a reasonable way to do it.   Independent of the need for this
technology in the standard public DNS hierarchy, the community
has generally been sympathetic to the need for enterprise and
other private hierarchies that are isolated from the public one.
Unless I misunderstand the technology --and I may well
misunderstand it-- the existence of such hierarchies would
justify look-aside techniques even if the root and all
second-level domains were already conventionally signed.  

But all of that, and I believe the relevance of question about
whether the DNSSEC technology needs "help", are questions about
the base DLV spec, not this IANA-oriented document.

If DLV is actually a useful mechanism (sometimes and to
someone), then there is a question about the IANA registry this
document proposes and its management.   That, it seems to me,
involves questions that should be addressed to ICANN Staff and
Board at least as much as to the IETF DNS community.  There
seems to be general consensus, both inside the IETF and in the
broader community, that zone- and response-signing are important
and that DNSSEC is the way to do it.  The main obstacle seems to
be agreement on who signs the root and in what form.  It has
been the main obstacle for some time now.  

My personal opinion is that, if the intended mechanism can be
deployed fairly quickly and generally accepted, having an IANA
DLV registry would only be a source of confusion.  But, if one
accepts that position, then it is reasonable for the IETF to ask
ICANN for a firm plan and schedule s.t., if the schedule cannot
be met, it is time for the technical community to deploy an
alternative because the original spec was too depending on a
single point of failure that had failed.  If ICANN cannot, or
will not, produce such a plan, the time for reaching that
conclusion probably moves up to "now".

> I would be troubled to see this go forward (with _any_ sort of
> IETF seal of approval), without the consensus of the relevant
> IETF DNS community behind it.

This seems far more relevant to draft-weiler-dnssec-dlv-03 than
to this document.

Just my opinion.
    john