Re: NGtrans - DNSext joint meeting, call for participation

["D. J. Bernstein" <djb@cr.yp.to>]

Crawford wants your signatures today to last for a month. What happens
if you decide tomorrow to change a machine's address list---for example,
adding or removing a second address?

Answer: An attacker can interfere with this change for 29 agonizing
days. All he has to do is replay the old data under the old signature.

The whole point of an expiration date is to stop this attack. Expiration
dates far in the future don't do that.

Are you willing to have your old data persist for a month after you make
a change? Of course not. This is why typical TTLs are at most 1 day, and
it's why typical expiration dates will be at most 1 day in the future.

Example: My cr.yp.to address is extremely stable. But I want the ability
to set up a second cr.yp.to web server with at most one day's notice.
That's why my TTL is 1 day, and it's why any signatures that I create
will expire within 1 day.

The question is not, as Crawford would have you believe, whether the old
data lasted for a month. The question is how much _warning_ you have
before the old data is replaced with the new data. That's what TTLs
measure, and it's what expiration dates measure.

Conclusion: The computer will sign every record every day. Renumbering
every day, with AAAA or A6, adds _nothing_ to this signing cost.

David Terrell writes:
> Did I miss somewhere where the expiration of the cryptographic
> signature was defined to replace the normal DNS TTL on the record?

In DNSSEC, the lifetime of a record is limited by the relative TTL _and_
by the absolute expiration date. See RFC 2535, section 4.4.

As for ``replace'': It's true that a better-designed protocol would
simply use absolute dates, not relative times. However, DNSSEC servers
are still supposed to manage TTLs for compatibility with non-DNSSEC
servers. See RFC 2535, section 2.3.3.

---Dan