At 16:19 -0500 3/5/05, Olaf M. Kolkman wrote:
I do agree with the general notion of chinese walls between child and parents but I'm picking on this particular point.
The signature validity interval over the DS is also a measure of faith in the protection of the private key _of_the_child. The security parameters of the child and parent are linked. Off course a parent could not care about its children but I'd think I'd allow for being more or less protecive for some of my children.
Having a brief conversation with Olaf last night, I think there is a question to ask here, but not necessarily in line with the words above.
As in - there's a replay problem with long-signed DS RRSets, but I don't think that the RRSIG(DS) validity is a measure of faith in the protection of the private key. And, it's not that a parent registry could not care less about the children, but rather that it would be untenable to do so.
That aside, the problem lies in the situation in which a child's private key is guessed, exposed, or otherwise compromised resulting in the ability of an unauthorized agent to generate signatures that can be verified with the child's public key. (Note - if the key is "lost" then it is no good to anybody.)
We need to solve for the case in which a child has just one DNSKEY record in the DNSKEY RRSet. This simplifies the discussion and fortunately, it captures the worst case scenario.
Here's what could happen:
1) The parent signs the DS RRSet for March 1 to March 31.
2) The child signs the DNSKEY RRSet for March 7 to March 10.
3) On March 8, the child realizes that someone is generating malicious sigs.
4) The child removes the DNSKEY RRSet from their zone, perhaps replacing it.
5) The child requests the parent remove or replace the DS RRSet.
6) Optimistically, the parent pulls this within seconds.
(Realistically, this will take longer. But if it happens in seconds,
we've captured the worst case scenario even more acutely.)Now at this time, a resolver can't get access to the now worthless key through official channels (i.e., authoritative servers and caches that aren't being duped).
However, since the problem is that the child key is available to a malicious party, there is a step 7, 8, 9,...
7) The unauthorized agent can now sign a new copy of the DNSKEY RRSet, as well as other parts of the zone. The new DNSKEY RRSIG could go until March 31.
8) The unauthorized agent can use this to get caches still holding the parent's DS RRSet [(step #1)] to authenticate false data.
9) The unauthorized agent can attempt to push the parent's DS RRSet to caches to prolong the agony beyond the TTL setting of the DS RRSet.
The "root" of the trouble is a lack of an explicit revocation mechanism in DNSSEC. (Not a complaint, just an observation.)
What can be done to limit the impact of such an attack?
One is to request that the parent change/roll it's keys - so that the DS RRSet will not validate beyond the TTL life. This would mean that the parent would have to resign everything in the zone (or at least what has been signed with the same key as has signed the DS RRSet in question).
That solution is heavyweight on the wrong party. It also means that the brunt of the fix is borne by a larger community (all delegations are hit). And finally, it opens up the registry to subscriber fraud via "crying wolf."
Taking a breath to look at what's in the message, I realize that I am not talking about something EPP specific, yet EPP is the impetus for the thread. This is still a DNSSEC operations problem to solve - and eventually we need to get EPP to support this.
With that in mind, what are the goals?
1) Lacking an explicit revocation mechanism (and it won't happen), DNSSEC relies on the validity period to end the effectiveness of a signature. Ergo, the shorter the validity period, the shorter the window of vulnerability of an abuse of the signature.
2) Generation of a signature imposes a noticeable computational cost, so there's a natural desire to want to delay signing unchanged data "again." I.e., lengthen the signature validity.
Goals 1 and 2 are diametrically opposed. This makes finding a natural and self-regulating setting quite hard. In most cases, (i.e., not the DS RRSet) the beneficiary of #1 and #2 are the same entity (the zone administrator), but when it comes to the DS RRSet, the beneficiaries are not (registrant benefits more by shortening, registry benefits by lengthening).
After speaking with Olaf again, he and I both have the same thought at this point. "The market should decide" the duration of the signature validity span. (This is open to debate.) I've been trying to think of someway to link the "optimal" validity span to some other parameter, but I don't think there's a wise choice. (I.e., linking it to the zone minumum ttl from the SOA probably ain't wise.)
To bring this back to EPP and the document at hand, the question is whether the protocol needs to contain data to support this.
I'm pretty much sold that EPP should carry a requested TTL from the client to server (begging the question of whether or not the server heeds this). I'm also nearly sold on the need for a "suggested max length of a validity interval." That's two items, less than (and different) from the current set of "TTL, vInterval, startDate, and endDate."
vInterval isn't the same as the suggested max validity interval. The former was a request to regenerate the signature (I think). The latter is a limit on how long the RRSIG is to last. I'd resist the temptation to make the validity duration be the same as the TTL.
Ordinarily, I'd feel that the child should not dictate what's in the parent zone. The exception here is because of the exceptional case of the DS RRSet - the only set that is only authoritative when coming from outside the "rightful" zone. (NSEC is in both.)
Having the suggestions for TTL and for the max validity interval does not mean that the business rules of the registry-registrar (server-client) have to heed them - in fact, error return codes are being built in to alert the client that the requests are not heeded.
For example, it's possible that a registrant may pay $10 per year for a name but has to live with 2 week signing intervals, but for $15 can get 1 week signing intervals. (All of this is absurd, but used to illustrate a point.) For $10 per year, suggesting a validity period of 10 days will be denied. For $5 per year more, the same request would be honored. I mention this example to illustrate the difference between what's the protocol and what is done in business rules.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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
