At 7:56 +0100 12/22/04, Olaf M. Kolkman wrote:
If the abuse [above] is "key compromise" then the RRSIG over the DNSKEY can be made with the compromised key and the RRSIG validity over the DS is what counts. What is, I think most important is that the child can signal the validity interval of the RRSIG over the DS RR. (we say something about that in draft-ietf-dnsop-dnssec-operational-practices, new version by the end of this week).
True, if the private key has been exposed/discovered then the a false RRSIG(DNSKEY) can be floating around. This puts the limiting temporal factor on the RRSIG(DS) and the TTL offered by the parent.
In -epp-secdns- there is a validity interval (vInterval) which is a topic of a documentation issue (meaning, the words aren't clear). vInterval is a length of time (I believe in seconds) to use for the RRSIG's expiration time, as in "start time + vInterval". (That's what the doc means, three folks reading it got three different meanings - hence the doc issue.) So, the draft already recognizes the need to be careful of the RRSIG validity period. Well, I think the situation is handled (even if I was one of the readers that got this wrong from an initial reading. ;) )
The TTL acts as damage control parameter. Although it does not safeguard in the case of attacks the short TTL does help in cases of for instance private key loss, where the DS needs to disapear from the DNS ASAP.
I don't agree with that, that the TTL isn't meant to protect against damage. The TTL represents a tradeoff of persistence versus performance. What the TTL limits is incoherence of data.
Perhaps sometime someone ought to write a document to clarify the relationship of TTL and DNSSEC.
(That's a joke.)
Remember, TTL's are not fool proof, so I wouldn't hold them up as an agent of security. A cache might get a signed RRSet with a maximum TTL of 900 seconds and decide to never decrement it on answer. The cache could give out the 900 second TTL up until the end of the RRSIG's validity period. (And beyond too - but a wary recipient would disregard the answer.)
Short TTL's do help lower mean time to repair.
When considering the TTL of the DS, it's a trade of cost and benefit. In this case the benefit is to one party (child) and the cost is to a different party (parent). (Assuming a canonical EPP setting.)
But short TTLs and short sig validity intervalls increase the cost on the operations. More queries, more frequent signing. If you allow EPP to sign tailored TTLs and signature validitiy intervalls you could be able distinguish service and thereby destinguish by valuable Euros.
Well, the appropriate terminology is "allow[ing] EPP to express a requested TTL" for this issue. EPP is only the expression of the request, not the processing of the request.
EPP commands don't necessarily launch an operation such as signing. In the conceptual model for EPP/DNSSEC, there is a database and other elements in between the EPP server and the DNS signer. If a 1000 EPP commands are received in 11 minutes to add DS's, the DNS signer may still run just once if the registry's policy is 11 minute updates to the DNS.
The TTL isn't an issue for this part of the operations. The TTL is an issue for the DNS servers (not the signer even). If I'm adding records every 11 minutes, I'm signing then - not a function of the TTL. Hopefully, the vInternval will be at least 660 seconds too.
(If 11 seems like an oddly particular number, it's because I wanted to use an oddly particular number in the example.)
Why would encoding business rules be bad, normally business rules go by the >name of local policy, don;'t they?
The issue here is a mix of (protocol development) environments. In DNSSEC, "local policy" dictates how a validator goes about it's work. I.e., what crypto algorithms to use, the sequence of operations, etc.
Business rules in the EPP sense don't impact the representation, parsing, transfer, etc., of the EPP protocol. E.g., perhaps the .example registry will not allow you to register names with vowels or digits in them.
The desire is for a registrar to be able to do business with .example and with .bert (which is "famously liberal" in what it accepts so long as enough Euros are attached). If the desire is to allow the registrar to use the same EPP client software to provision names from .example and from .bert, then the EPP protocol elements ought not have the no vowels nor digits rule in them.
Like the 11 minute example above, this may drive a registry to say that vInternval must be at least 1320 seconds, or maybe 3600 seconds, or maybe a number based on a price paid for the name. The TTL might be given a lower limit of an hour and an upper limit of 1 week - these numbers might be adjusted when engineering a DNS constellation to meet a service level agreement.
As an aside, limiting TTL from being too high might be a way to prevent a person from buying a name for 3 months and then hoping to reap benefits by having healthy caches hold the name for a year. Not a realistic threat - as one popular DNS implementation caps all TTL's at one week anyway - certainly not economically useful, but maybe useful to hide from whois/iris exposure.
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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
