Re: NGtrans - DNSext joint meeting, call for participation

[Robert Elz <kre@munnari.OZ.AU>]

    Date:        Wed, 25 Jul 2001 06:28:32 -0700
    From:        "D. J. Bernstein" <djb@cr.yp.to>
    Message-ID:  <E15POiG-000Jy5-00@psg.com>

  | Crawford wants your signatures today to last for a month.

I doubt that Matt cares how long anyone's, but his own, signatures last.

  | What happens
  | if you decide tomorrow to change a machine's address list---for example,
  | adding or removing a second address?

I wait until the previous signed record is ready to be resigned, and then
I sign new ones, with different data, different TTLs, or anything else
that I want.

  | 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.

This has nothing whatever to do with attackers - the only way an attacker
can interfere with this is if you're attempting to bypass the protocols.

What you're really saying here is that people shouldn't use long
expiration dates.   What you should be doing, is explaining the pros
and cons of different signing policies.   I know that for most of
my systems, nothing ever changes - and if something is to change,
I can wait several weeks for it to happen (generally it takes that
long to build up the energy to make the change anyway).

Trivial stuff like ethernet cards dying, etc, can be handled by just
configuring the (IPv6) address of the system to what it used to autoconfig
to, until it is time to update the DNS (if ever).

Adding new interfaces, addresses, etc - all takes planning.  That all
takes time.  Now certainly when designing my signing policy I should be
taking into account all of these factors.  But when I do that I know
that I am not going to come up with any simple number as the answer
for everyone.

  | Are you willing to have your old data persist for a month after you make
  | a change? Of course not.

No, but if I define things that way, I'm prepared to wait a month before
making the change, so I can do it properly.  If I didn't want to wait that
long I'd use a smaller expiration time.

  | This is why typical TTLs are at most 1 day, and

Yes, and because they're cheap (the cost of a 1 day, compared to 7 day
expiration is negligible).

  | it's why typical expiration dates will be at most 1 day in the future.

But that's not cheap.   And it almost certainly simply won't work in
general.   Signing, and retaining security, is a time consuming
business (the CPU time consumed is not what I am measuring here, but
the human time).   The data needs to be somehow carried to the key
(which cannot be exposed anywhere near any network), the signing done,
and then the data carried back again.   Doing that once a month for
most people just might be tolerable - once a day and all that will
ever exist are expired signatures.   After all, how many sites are
going to have people (people with authority to get at the keys)
available every day of the year (no holidays permitted) to resign the
zone file?

  | 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.

You can do that with your private zone file - and hope that you're
available to resign every day (or you can blow security and stick your
key on the server and have it all automated).

Don't expect almost anyone else to follow your example.

  | 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.

That's absolutely true, except I doubt that Matt expects anyone to
believe what you claim he does.  It certainly isn't what he said.

  | Conclusion: The computer will sign every record every day.

And that's not a conclusion at all, but a speculation, and most likely,
for most sites, an obviously bogus one.

  | Renumbering
  | every day, with AAAA or A6, adds _nothing_ to this signing cost.

That would be true, if you were resigning everything every day, but
almost no-one is going to be doing that.

For A6/AAAA records, which is where this discussion started, the
average system will retain the same set of interface identifiers for
long periods (very long periods), and on the odd occasions when those
are to change, a delay before making the change is entirely acceptable.
It doesn't have to happen right now.   Nothing is going to require that.
Hence a long expiration time is just fine (how long will depend upon
individual site requirements, for me, I think 3 months would be about
right).

On the other hand, someone else can command me to change the upper
parts of the address (my ISP just changed its ISP for whatever reason,
all their addresses are now from a different block, they're keeping
the old ones for a week...)   In that situation I have to be able to
change the upper bits quickly, those can be out of my control.  So
that part I need to be able to update quickly, that one I will have to
resign fairly frequently (I'd probably make it once or twice a week
though, not once a day).

  | As for ``replace'': It's true that a better-designed protocol would
  | simply use absolute dates,

That would be nice, if we could mandate that any two systems use the
same idea of the time.   Until that happens (like never) relative times
are what works (well enough).

kre