Subject: RE: [dnsop] comments on draft...epp-secdns-05

From: Marcos Sanz/Denic <[email-masked]>
Date: Thu, 2 Dec 2004 07:52:09 +0100

Scott,

> If we remove the DNSKEY data, the RRSIG stuff goes with it because
> <secDNS:sig> is currently part of <secDNS:keyData>.  Are you suggesting
> something else?  If we remove it I can see a need for some text to 
describe
> the operational issue that you've touched on above.

Yes, some text could be added. How about something á la:
"In order to evaluate the received DS records, the registry MAY issue DNS 
queries to dig the DNSKEY RR from the registered domain's apex. To provide 
support for this case, it is RECOMMENDED for the registrant to have this 
data online in the DNS tree before proceeding with the domain operation"?

Best,
Marcos

.
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: Thu, 2 Dec 2004 11:00:26 +0200

>data online in the DNS tree before proceeding with the domain operation"?

One of the issues in the original EPP work was to 
divide protocol/interface requirements from 
business rules requirements.

I'm all for excessive documentation.  I think 
over explanation is better than under - case in 
point wild cards.  Here are the thoughts that 
come to mind here.

1) I'd omit any RFC 2119 verbiage from 
operational recommendations that do not pertain 
to the behavior of the protocol per se.  I would 
"drop the tone down" a bit to discussion, not 
specification.

2) As much as I hate cleaving documents, this 
might be a place to do this.  I'd like to 
streamline the specification document and get it 
greased as much as possible all the while 
retaining the conversations held here.  Akin to 
the rewrite of the WHOIS specification by Leslie 
Daigle a few weeks back, taking out the policy 
from that specification/document, I think it 
would behoove us to do something similar.

I'd think it would be interesting to have a 
discussion of business rules for DNSSEC, probably 
spring boarding from the work and thoughts that 
Miek has done and expressed, as well as what 
Marcos has expressed in the thread.

FWIW - I really think that for the purposes of 
provisioning, only the DS needs to be transferred 
under the security envelope of EPP.  I'm not 
against registries retrieving the DNSKEY and the 
RRSIG data at all, but that can be done via the 
already defined protocol we call DNS.  (In one 
way, it'd be like reinventing a wheel, flat tire 
jokes not necessary.)

I think of it this way - the sending of the DS 
record is akin to a DNS NOTIFY, but in a 
different control plane - that plane being the 
provisioning layer, not the port 53 master-slave 
control plane.  The provisioning control plane is 
a bit different from the DNS control plane, 
there's no usurping of functionality.

I think that it is a MUST that the DS travel in 
the provisioning control plane to achieve the 
level of security needed in that plane (shared 
registry model requirements, etc.).  I think that 
if the DNSKEY and RRSIG are there too, you are 
just repeating data.  With the DS traveling this 
way, a registry has a means to validate the 
receipt of a DNSKEY and RRSIG via the DNS data 
plane.

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

I think my jabber client and SMS phone are talking about me behind my back.

.