on-list, was Re: off-list was Re: [ietf-provreg] Revision of 4310

[Edward Lewis <Ed.Lewis@neustar.biz>]

(Altered the subj line as we are back on topic. ;))

At 11:08 +0000 1/27/10, Eduardo Duarte wrote:

>Well when I was thinking of this flag I was thinking that it would mean if the
>key is publish in the parent zone and I was not thinking to much on 
>the create/
>update commands but more on the info... :P

This was as I suspected.  (Read: I'm about to jump on a soap box.)

>On our work model a domain can have more then one key associated with domain
>and they can be in a active or inactive state where active means publish or
>unpublished  in the parent zone.

I'm going to argue about registry practice here.  I don't mean to 
criticize, but I feel compelled to express my opinion.

I think it is a good idea for a registry to ONLY collect information 
that is supposed to be in or support the public DNS or WhoIs.

I need to really explain this blanket statement.

"supposed to be in" includes data about suspended/blocked/reserved 
domains (those not actively delegated but still being associated to 
an entity).  So a domain name that that has elapsed is okay - it is 
"supposed to be in" except that something else went wrong - and 
retaining it's last known NS set is a good idea.

"supports" refers to data that is related to functions like billing 
or contacts that are used to make sure the registration is "fresh (as 
in active, live, the guys out there are still runnning a server, 
etc.)."

"public" besides the usual stuff we think is public, I mean to 
included here (quasi-)confidential information that is disclosed to 
authorized third parties such as law enforcement.  I include this 
because not all registries have an Internet accessible, publicly 
viewable WhoIs but do have the requirement to identify registrants to 
authorities (legal or otherwise).

More to the point, I think it is very unwise for a registry to act as 
a data escrow facility for its registrants (unless you want to expand 
your mission or business to include that).  More precisely what I'm 
trying to say is that escrow is not part of provisioning.  IMO - 
registration should be about the "here and now" the relationship of 
entities to objects and vice versa.

Because of that opinion, I wouldn't think to add such a flag - a flag 
of "show this, don't show that."

(Again, please don't be offended, this is just a feature I feel adds 
complexity and burden to the registration interface and I want to be 
clear why I say the rest of the things.)

>When adding a key I dont see the problem of it becoming automatically publish
>in the parent zone and the old key to be unpublished as soon at is expire or
>remove.

The true authority of a domain registered in your domain is the 
registrant.  Outside of you "granting" them the title to the name, 
they call the shots.  That is, the registry should do nothing 
"automatic" to the domain.  (Yes, refreshing DNSSEC signatures is the 
parent's job - but that's a statement about the parent's DNS data, 
not the child's.)  All actions regarding the registrant's domain 
should come from the registrant (or their agent, etc., /registrar).

And remember - keys don't expire in DNS, just signatures.

So I don't think you should need this flag.  Or anyone should need 
this flag.  (Not that adding it is a bad idea, and it can be done.  I 
am cautioning against ever using it.)

>But lets say the owner of the domain keep just adding keys!

And then there is that.  If you become an escrow agent, you enter 
another level of, well, hell.  You have to worry about registrants 
DOS'ing you, eating up your disk and memory.  What's your data 
retention policy, privacy policy, etc?  How do you back things up? 
How long do you store stuff?  When is data deleted?  This is more of 
a repeat of my "don't escrow while provisioning" message.

>I know that some other registries use this model for managing the client
>keys and that was why I asked if this was already been discussed...

We do not want to touch any keys of our registrants, much less manage 
them.  That is why we only will take the DS record - the hash of the 
key.  We are very clear not to even see private keys, not public 
keys.  That is all the registrant's misery.  We just (plan to) 
register the hashes of the keys as the registrant submit them.

The registrants are completely in control of their key management. 
If they do frequent key changes, so be it.  If they never change the 
key, so be it.  We just report what they tell us to report.  Just 
like the NS records - we don't mess with them, we don't mess with the 
DS records.

(I don't mean to go commercial but to be clear I am writing this 
thinking solely as part of the registry team, not the managed DNS 
services team.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se