[DNSSEC-Transparency] Validity wrt TTL

Paul Wouters <paul at nohats.ca> wrote Sat, 5 Mar 2016 06:42:06 -0500 (EST): | On Thu, 11 Feb 2016, Linus Nordberg wrote: | | > In a long response on the getdnsapi-users list [0] I reasoned about | > validity and time. I'm sure this list could have good input on this. | > | > [0] https://getdnsapi.net/pipermail/users/2016-February/000164.html> | > A short version is | > | > - should a log limit submissions to those who are "fresh"? | > | > - if so, what are resonable values for freshness? | > | > - would this be useful for more than spam mitigation, i.e. good for | > attribution as well? | | The problem is that if you don't log keys with very short validity | times, attackers can use those values so they won't end up in the | logs - and perhaps the original/real owner will never find out | about these bogus keys. OK, so a log mustn't reject on short validity if we want to catch all misissuance. What about freshness? Should a log reject a submission if any RRSIG has a validity period that's too far off in the past or the future? I like the idea of logs accepting old and maybe future keys. Old because someone who's been off the (real) internet for some time might have valuable compromising data to share. Future because zone owners might want to submit in advance, maybe.