For security considerations, only the signature expiration time is significant.
The problem is that an attacker with control of the key could in theory set the expiration time to 2099 or something stupid. But that is already a known security consideration (or was). If the attacker has only one RRSIG then it is sufficient to have a limit on the lifetime of the RRSIG. But an attacker could also generate themselves multiple RRSIGs for the whole time interval in question. So ultimately it comes down to how the keys are managed in the upstream zones and whether one of those can be rolled in the case of a major compromise. So there is a time window for attack in the case of administrator incompetence, but I have a really hard time seeing how it can be closed with a revocation system that was established through the same root of trust. On Tue, Mar 5, 2013 at 7:19 AM, Olafur Gudmundsson <[email protected]> wrote: > > > On Mar 4, 2013, at 11:45 PM, Martin Rex <[email protected]> wrote: > >> Mark Andrews wrote: >>> >>>> >>>> TTL is *NOT* signed. >>>> >>>> While there is an original TTL field that is signed: >>>> http://tools.ietf.org/html/rfc4034#section-3.1.4 >>>> >>>> this will not prevent any intermediary (attacker) to produce >>>> new DNS responses with TTLs less than or equal ot the original >>>> TTL field whenever necessary within the remaing RRSIG lifetime. >>>> >>>> -Martin >>> >>> And the sematic difference is what? When you produce a RRSIG you >>> are saying to the world "all these TTL values are valid". It's >>> just short hand for generating TTL+1 RRSIG covering each possible >>> value. >> >> The original question was whether TTL provides revocation. >> No, TTL can not possibly provide revocation (for DNSSEC protected >> DNS records), because it can be made up at will by an intermediary >> attacker. Only the RRSIG lifetime and rolling the zone key are >> reliable in getting rid of DNSSEC protected data that is no longer >> to be seen as valid. >> >> It is like that "limited to one withdrawel per day" limit on >> ATM cards that is implemented by an unprotected counter that >> is stored on the ATM card itself. The crooks with a >> card reader/writer can simply reset that counter on the magnetic >> strip after withdrawal and perform multiple withdrawels >> (usually on ATMs of different banks) on the same day. >> > > > Martin and Mark, > You are both right and neither fully wrong :-) > > For most practical cases we can think of DNS time based "revocation" as two > different revocation times. > > old RRset TTL == is when an publisher of the record can assume that MOST > resolvers will have purged the old record from their caches. This timer > starts when the new RRset is distributed to the LAST authoritative server for > the zone. > > Signature Expiration time == Absolute time upto which an ON-PATH adversary > can reuse the old RRset and have it accepted by a targeted victim. > > The difference is the scope of the revocation, MOST vs Targeted, also if the > adversary is ON-PATH then it > can do lots of other things to the victim. > There are differences in "how much" ON-PATH the adversary is, in some cases > they are listening to the query traffic on the write in other cases they have > succeeded in redirecting DNS traffic to resolvers under their control. > > > > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane -- Website: http://hallambaker.com/ _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
