Subject: Re: [dnsop] ...epp-secdns-05...

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 29 Dec 2004 10:17:36 +0100

I've re-skimmed :-) the archive and to answer Ed's question:

 I cannot think of an environment where the DNSKEY approach will work
 and the DS approach "WILL NOT" work.

I still think it is preferable for the child zone owners to deal with
keys only. On the other hand we have to remember that EPP is a
registrar-registry protocol. The protocol does not enforce the
registrant (the zone owner) to deal with DS-es. In fact I can imagine
the registrar's tools to deal with the dificulties of DNSKEY to DS
transformation (e.g. web-interface that does a query, presents a
number of keys, user clicks, presents creditcard details, and DS is
generated).

There are two reasons why I think it may be usefull for the registry
to have the DNSKEY:

  - troubleshooting: by storing both the DS and the DNSKEY in the
    whois database there is an out-of band mechanism to troubleshoot
    broken set-ups. 

  - DS regeneration: That only seems useful in the case the hashing
    algorithm is to change. And in the case where the hash algorithm
    needs to change troubles me a bit. But if SHA1 turns out to be
    vulnarable we will have to do an algorithm roll too there are
    larger issues at hand. In other words this is not a strong
    motivation.

Concluding: the only argument for having the DNSKEY at the parent is
to store it in the WHOIS together with the DS in order to allow for
out of band troubleshooting. Is that important enough to allow for
the DNSKEY to travel over EPP?

DNSKEY as an attribute of the DS element is a fine method to acomplish
this as there is even a more direct link between the DNSKEY and the DS
record.

-- Olaf

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Edward Lewis <[email-masked]>
Date: Wed, 29 Dec 2004 16:56:51 -0500

>the DNSKEY to travel over EPP?

I'd still say no.

As registries grow to over 1 million objects and the number of 
different implementations of DNS grow, troubleshooting like this will 
disappear.  If the registrant hands in a DS to a registrar, who then 
passes it opaquely to the registrar - what's to troubleshoot?  If 
what went in = what is there, the problem is then all on the 
registrant's side.  If there is processing in the registrar or 
registry - then there is something to troubleshoot.

I like the philosophy that neither half of the public/private key 
gets to the registry.  It keeps a very federated, decentralized feel 
to the security model.  I'm not sure that this is quantifiable 
though.  Let the registry collect only what it must - after all, it's 
going to be a large collection already.

Keep in mind that if the DNSKEY were to be totally removed from EPP, 
there is still DNS to move the key from child to parent - barring bad 
firewall configurations, nasty NAT's, etc.

>this as there is even a more direct link between the DNSKEY and the DS

I think it is appropriate to keep it that way - because the *only* 
reason to leave DNSKEY in EEP at all is to counter layering 
violations in other protocols and devices.  (Speaking of the problems 
of firewalls, NAT's, etc.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html