On Thu, Mar 03, 2005 at 05:45:40PM -0500, Scott Hollenbeck wrote:
Mark: are you suggesting that what's currently in there now as vInterval more correctly identifies the RRSIG lifetime?
I'm not sure it is needed as it seems a bit redundant to me.
I have thought about the date and interval features a bit. I have growing concerns in two contexts about whether these are beneficial in EPP.
In the context of the DNSSEC protocol, I think that the security parameters of one zone should not be linked to the parameters in another zone. This is a long standing opinion of mine, dating back to when we (folks in design teams 2-3 years ago) talked about "trimming" the TTL's based on signature lifetimes.
In this case, the signature validity period of the DS RRSet is something that should be wholly determined by the parent. The validity period is a measure of the faith in the protection of the private key. The TTL on the DS RRSet is not a security parameter, but rather a measure of the persistence of the data.
An aside: that is why I don't violently oppose trimming a TTL of a RRSet to the end of the validity period of it's own RRSIG. I may even agree to the trimming within the zone, e.g., the DNSKEY validity, but not beyond that.
This may seem to give too much power to the parent. But recall that the child signs the DNSKEY RRSet. There was a time at which I felt that the DNSKEY RRSIG was unnecessary for a one-key (i.e., KSK and ZSK are the same key) zone. After some discussion, the DNSKEY RRSIG, which in this case may be just a self-signed signature, provided its own validity period.
E.g., looking at a parent/child...
In the parent:
delegation.example. NS ns1.delegation.example.
NS ns2.delegation.example.
DS <refers to key #1>
RRSIG DS from March 1 to March 31
NSEC <next name>
RRSIG NSEC ...In the child:
delegation.example. SOA <soa stuff>
RRSIG SOA
NS ns1.delegation.example.
NS ns2.delegation.example.
RRSIG NS
DNSKEY <key #1>
RRSIG DNSKEY from March 7 to March 14What is important to keep in mind is that the signature validity is supposed to be only a measure of the goodness of the product of the private (signing) key and not a measure of the validity of the data protected. Don't be tempted to think of signature dates as a means to judge how fresh data is, or if one set of data is fresher than the next.
Even though the signature by the parent is good for the whole month, what it points to may only be good for the 8 days shown. That's the "safety belt" worn by the child.
What I didn't include above is the TTL. It's possible that a cache somewhere will accept, verify, and decide to hold on to the parent's DS record for X seconds. During the passing of the X seconds, the child may change it's DNSKEY RRSet, and assuming the cache no longer has the DNSKEY RRSet, let's say the cache gets a another (can't really say newer) one.
At this point the cache may not be able to cleanly verify data, if the new DNSKEY RRSet contains no keys that are referred to in the DS RRSet.
At this point I need to ask these questions: Is this a problem of the validity period or TTL? Or is it a problem with the validity-checking algorithm?
It could be either, that's why I am asking. I don't really think it is the signature validity, but it could be the TTL. Trimming the TTL on the DS RRSet to the DNSKEY RRSet might be worthwhile - with a lot of caveats. Should this trimming be done at the parent or at the cache?
I don't think you want to have too much trimming at the parent because of the child. One of DNS's strengths is it's loosey-goosey (yeah, I said it) management scheme. DNS tolerates mismatches in NS RRSets, etc. DNS "only" hints down, unless you take the indication of lameness as an upward referral. While DNSSEC was plagued by a weak delegation point interface, scaling DNS has benefited from it.
This is why I resist a lot of efforts to make the parent base it's parameters on the child. I don't want there to be a "feedback loop" effect.
Of course, the parent has to set delegation parameters according to the child's wishes - like the contents of the NS RRSet and DSRRSet. Those are matters for the registration activity. But matters of zone security fall into issues like name server management, etc., i.e., infrastructural concerns. I'm not of the opinion that we want to open this up too much to the child's meddling.
From the context of a registry operator, accepting the dates that a DS RRSet is to be valid is proposition that I think needs some thought. Not that I wouldn't want to offer this beneficial service, but it's not something that is currently in line with registry practices.
There is only one kind of date information held concerning an object, that being it's lifetime. (Created, last modified, expires, billing, grace period, etc., all relate to the object's life time.) Off hand I don't know of any other registry that holds data about the future of an object - just what's there now. I.e., the name servers attached to an object are assumed to be current, etc.
Now, I understand that there is a difference between business rules and what's in EPP. That may be part of my concern here. But I'd like to examine whether it makes sense for a registry to even collect the validity period data.
Is there a registry willing to add to it's database a schema for "these are future edits to make to the registration?" Would the schema be capped at the expiration of the object? Would the schema's contents be altered automatically upon a renewal, an automatic renewal? How would a registrant(or registrar) get access to this future information? A special IRIS interface?
Besides the debate of implementing this new interface, the concern I have is garbage collection - once data's validity passes, is it forgotten? Will it have to be logged incase of forensic activity?
And then there's the "feedback concern" - what happens if a registrant submits a new DS RRSet for June, but in May is acquired in a merger and things like keys, etc., are forgotten? Can we be sure that the registrant will stay in synchronization with their plans?
Thinking like this makes me think that we ought to treat the DS RRSet just like the NS RRSet. OTOH, the NS RRSet is authoritative at the child, the DS RRSet authoritative at the parent. Nevertheless, I begin to question the utility of the validity periods (and resigning frequency). The TTL problem? I would need to see some impirical evidence of whether the parent ought to be mindful of the child's desires (inspire of the feedback look concern) or whether the issue ought to be built into the validation algorithm.
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar
Achieving total enlightenment has taught me that ignorance is bliss. . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
