Subject: Last call comment on draft-weiler-dnssec-dlv-iana-00

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 19 Sep 2007 17:55:28 +0200

Dear colleagues,

In this message we would like to raise a number of issues we have  
identified with the proposal to establish a " DNSSEC Lookaside  
Validation (DLV) IANA Registry" (draft-weiler-dnssec-dlv-iana-00).

* Domains under .arpa

The document requests the establishment of a sub-domain of .arpa that  
is to be used as the "anchor" for the domain-name-tree that can be  
used with the DLV algorithm described in draft-weiler-dnssec-dlv-03.  
The IAB has specific responsibilities with respect to the  
establishment of domains under the .arpa domain [RFC3172]. It is  
based on that responsibility that we write this last-call comment.

RFC3172 specifically calls for a description of the delegation, and  
the hierarchical name structure in an IETF standards track document.   
We observe this document does not give the crisp and clear  
instructions that are needed to maintain the zone. IANA would need  
very precise instructions on how and when it needs to add data to the  
DLV infrastructure. That the document requests a dnssec.arpa domain  
is a detail that should not be overlooked.

In addition, we believe that the reason that RFC3172 requires a  
standards track document is that a domain under .arpa is only to be  
delegated if there is a use for long term infrastructure needs.  
Arguably DLV is a transition mechanism.

* Service costs and competition.

This document is requesting IANA to establish a service that could be  
costly to implement. It can be argued that the  operational costs  
involved with the maintenance and publication of this registry are  
significantly higher than for other registries that IANA maintains  
for the IETF.

Even though IANA is currently providing their services with respect  
to registration of  technical parameters for free we should work from  
the assumption that at one time we, the IETF/IAOC, might have to pay  
for the maintenance of the technical parameter registries.

Although IANA is in a unique position that it has an established  
relation with the TLD operators and the number registries for the  
domains under in-addr.arpa, it is not the only party that could offer  
this service. The DLV protocol allows multiple parties to start a DLV  
registry at arbitrary locations in the namespace. In fact, one might  
expect a competitive market of DLV registries. Given that we think  
that there are no strong technical arguments for a unique domain  
under the .arpa domain, we observe that the establishment of a dlv  
domain under .arpa needs further thought with respect to how the IAB/ 
IETF would influence the above mentioned market.

* Relation IANA and IETF.

The relation between IANA and the IETF are covered through an MOU  
[RFC2860]. The guiding document for the establishment of .arpa  
[RFC3172] specifically mentions the delegation of new domains  
under .arpa being done as part  of that MOU.

Section 4.3 is relevant to the issue we want to raise here

>  4.3. Two particular assigned spaces present policy issues in addition
>    to the technical considerations specified by the IETF: the  
> assignment
>    of domain names, and the assignment of IP address blocks. These
>    policy issues are outside the scope of this MOU.

The establishment of the DLV registry bootstraps on relations that  
IANA maintains with the TLDs on the basis of the maintenance of a  
space that is specifically outside the scope of the MOU between the  
IETF and IANA. We feel that by stepping over this boundary we would  
also get involved in some of the policy issues regarding the  
"forward" name space.  That there are policy issues with getting the  
root signed is duly known. So if the IETF were to establish this DLV  
registry in .arpa, than that might be seen as an attempt to outrun  
the policy making process. We therefore feel that the IETF should be  
extremely careful in making a request of this sort.

* Conclusion

The IAB, obviously, favors expedient deployment of DNSSEC in the DNS  
root.

In absence of such we understand that mechanisms such as DLV or the  
publication of lists with TLD trust anchors could aid deployment.  
However, the IAB does not support the establishment of a domain  
under .arpa combined with a request from the IETF to IANA to  
establish such a service as that would implicitly be based on the MOU  
between RFC3172. However,
  - if there is IETF wide consensus on a proposal to establish  
a .arpa zone;
  - if such proposal would deal with the 'competition' issues  
mentioned above;
  - if such proposal should contain much more detail on how to  
establish and maintain authentic DLV entries;
  - and if said proposal describes the other requirements for such  
registry such as key management;
then given such IETF consensus the IAB will explore how such registry  
can be established without violating the MOU.

On behalf of the IAB,

--Olaf Kolkman

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

--==From [email-masked] Wed Sep 19 12:04:17 2007
From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 19 Sep 2007 17:55:28 +0200
To: [email-masked]
Cc: IAB IAB <[email-masked]>
Subject: Last call comment on draft-weiler-dnssec-dlv-iana-00

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)

Dear colleagues,

In this message we would like to raise a number of issues we have  
identified with the proposal to establish a " DNSSEC Lookaside  
Validation (DLV) IANA Registry" (draft-weiler-dnssec-dlv-iana-00).

* Domains under .arpa

The document requests the establishment of a sub-domain of .arpa that  
is to be used as the "anchor" for the domain-name-tree that can be  
used with the DLV algorithm described in draft-weiler-dnssec-dlv-03.  
The IAB has specific responsibilities with respect to the  
establishment of domains under the .arpa domain [RFC3172]. It is  
based on that responsibility that we write this last-call comment.

RFC3172 specifically calls for a description of the delegation, and  
the hierarchical name structure in an IETF standards track document.   
We observe this document does not give the crisp and clear  
instructions that are needed to maintain the zone. IANA would need  
very precise instructions on how and when it needs to add data to the  
DLV infrastructure. That the document requests a dnssec.arpa domain  
is a detail that should not be overlooked.

In addition, we believe that the reason that RFC3172 requires a  
standards track document is that a domain under .arpa is only to be  
delegated if there is a use for long term infrastructure needs.  
Arguably DLV is a transition mechanism.

* Service costs and competition.

This document is requesting IANA to establish a service that could be  
costly to implement. It can be argued that the  operational costs  
involved with the maintenance and publication of this registry are  =============1556581002==--

---

From: David Kessens <[email-masked]>
Date: Wed, 19 Sep 2007 16:01:15 -0700

Olaf,

> The IAB, obviously, favors expedient deployment of DNSSEC in the DNS  

Is there any activity by the IAB to achieve this goal ?

David Kessens
---

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Sep 2007 15:51:52 -0400

> domains under in-addr.arpa, it is not the only party that could offer 

   How much of the IAB's concern is that it's under .arpa, and how much
is the concern that IANA will be unable to (afford) do this work?

   If having the DLV under olaf.NLnetLabs.nl (or some other convenient
prefix) solves enough of the concern, could we address the IANA requirements 
separately?

> The establishment of the DLV registry bootstraps on relations that IANA 
> maintains with the TLDs on the basis of the maintenance of a space that 
> is specifically outside the scope of the MOU between the IETF and IANA. 

This suggest that actually, the IETF is not the only organization that could 
ask IANA to do this.  IANA could do it on their own, for instance.

> We feel that by stepping over this boundary we would also get involved 
> in some of the policy issues regarding the "forward" name space.  That 
> there are policy issues with getting the root signed is duly known. So 
> if the IETF were to establish this DLV registry in .arpa, than that 
> might be seen as an attempt to outrun the policy making process. We 
> therefore feel that the IETF should be extremely careful in making a 
> request of this sort.

I think... there is too much thinking occurring!
Just do it.

> The IAB, obviously, favors expedient deployment of DNSSEC in the DNS root.

It still hasn't happened.  If it were going to happen quickly, it would 
already be done. I don't see it happening in a reasonable amount of time.

> However, the IAB does not support the establishment of a domain under 
> .arpa combined with a request from the IETF to IANA to establish such a 
> service as that would implicitly be based on the MOU between RFC3172. 

> However,
>  - if there is IETF wide consensus on a proposal to establish a .arpa zone;
>  - if such proposal would deal with the 'competition' issues mentioned 
> above;
>  - if such proposal should contain much more detail on how to establish 
> and maintain authentic DLV entries;

Thanks for leaving the conversation open.
It sounds like the IAB would be happy to create such a zone if it wasn't
IANA doing it, i.e. other than the competition issue, the IAB is not opposed 
to dnssec.arpa.

Contrary to what I write above, that the IAB is actually more concerned about 
IANA than about .arpa pollution?

The competition issue is, I think, moot. Anyone can start a DLV.

IANA already has a monopoly on various numbers/name spaces. It does no 
politics about which zones can be created/deleted/etc. It just maintains 
relationships. IANA has no monopoly on having relationships with all the TLDs 
and reverse zone owners, but IANA already has those relationships. We just 
want to leverage them.

It seems that if IANA were to create dlv.iana.org, that there could be no 
concern from the IAB about giving IANA a privileged position in .arpa. Is 
this correct?

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 24 Sep 2007 09:31:18 +0200

> Is there any activity by the IAB to achieve this goal ?

In addition to statements like the sentence above there  is a bit of  
'silent diplomacy'. Besides, under the header of "leading by example"  
we are working with the operators of the zones for which the IAB has  
certain responsibility to get those signed (e.g. [1]). For example  
the RIPE NCC will be announcing that they will be signing E164.arpa  
any time soon (see [2],[3] for the ongoing message exchange).

--Olaf

[1] http://www.iab.org/documents/correspondence/2006-05-15-IAB- 
request-to-IANA-to-sign-DNSSEC-zones.html
[2] http://www.iab.org/documents/correspondence/2007-07-05-ripe-ncc- 
dnssec-e164.html
[3] http://www.iab.org/documents/correspondence/2007-07-24-iab-itu- 
dnssec-e164.html

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: David Conrad <[email-masked]>
Date: Mon, 24 Sep 2007 12:48:13 +0200

> request-to-IANA-to-sign-DNSSEC-zones.html

On this particular issue, IANA is working to make a production  
version of the signed zones we're responsible for available within  
the next couple of weeks.  You can see the status of our pre- 
production testbed at <https://ns.iana.org/dnssec/status.html> and  
the zones mentioned on that page are available for zone transfer at  
ns.iana.org.

Note that the signed root on ns.iana.org is not the "real" root since  
the "real" root is published by VeriSign to the 13 root name  
servers.  The content is the same though (with the obvious exception  
of the DNSSEC-related RRs) and we'll be actively soliciting folks  
who'd like to be involved in testing of an experimental DNSSEC signed  
root as soon as we go into production with the other DNSSEC signed  
IANA zones.

Regards,
-drc

---

From: David Kessens <[email-masked]>
Date: Mon, 24 Sep 2007 18:01:28 -0700

Olaf,

On Mon, Sep 24, 2007 at 09:31:18AM +0200, Olaf M. Kolkman wrote:
> 'silent diplomacy'.

Considering that the root is still not signed, is the IAB considering
a different approach than 'silent diplomacy' towards achieving this
goal ? I would like to note that the RIPE community has issued a
public statement (http://www.ripe.net/ripe/wg/dns/icann-root-signing.pdf)
while I have not seen anything directly addressed to ICANN from the
IAB. I would expect that the IAB, with it's Internet Architecture
interest in mind, should be taking a much more active and public role
as delays in DNSSEC deployment at the root level may very well inspire
short-term non optimal solutions that will affect the overal security
architecture as defined by the IETF for the DNS.

> Besides, under the header of "leading by example"  

I appreciate this.

David Kessens
---