Edward Lewis wrote:
There's the issue of whether this matters at all. A DS set with a high TTL does not mean that an abuser of the DNSKEYs can extend the length of an attack. The child zone can always have a short validity period on the RRSIG covering the DNSKEY set, limiting the usefulness of the overly long TTL'd DS. The risk to the child of high TTL'd DS sets is, in reality - err - theory as we haven't set this up, a longer "mean time to recovery" because of the persistence (a la phosphorus) issue.
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).
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.
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.
As far as the apparent risk that a child can select an abusively low TTL, the parent can have a "business rule" setting the lower limit of the TTL to a certain number. Encoding a business rule per se would be a bad, bad thing in the protocol definition. But recommending that a registry adopt such a business rule ought to be in the security considerations section.
Why would encoding business rules be bad, normally business rules go by the name of local policy, don;'t they?
My 2 cents (pick a currency of more or less value:-)
-- Olaf
. dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
