Subject: Re: NGtrans - DNSext joint meeting, call for participation

From: Matt Crawford <[email-masked]>
Date: Sun, 22 Jul 2001 13:30:13 -0700

> ``Administrators normally insist on being able to change their records
> with at most a few days notice,'' my web page says, as a starting point
> for analyzing the expiration-date security issues.

Yes, it does indeed say that.  It has to say it, because imposing
that ad-hoc restriction is necessary in order to drive to the
conclusion you want.  Bu tthat doesn't make it so, especially when
different records record information with clearly different
volatility.

> Matt Crawford writes:
> > then the signatures on the A6 records covering interface identifiers
> > and subnets can be valid for a long time,
> 
> No, they cannot, because that would allow an attacker to interfere with
> updates. This is the security issue analyzed on my web page.

No, it is not analyzed.  What you assert is true, but you have not
explored the ramifications.

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Matt Crawford <[email-masked]>
Date: Sun, 22 Jul 2001 13:30:25 -0700

> Matt Crawford writes:
> > So if it's all right for your
> > interface ID and/or subnet information to persist for a month, but
> > you want to be able to change your global prefix(es) on a day's
> > notice, you get a 30-to-1 work savings on almost all of your RRsets.
> 
> No. Under your one-month assumption, all records will be signed at least
> once a month, to eliminate the expiration-date security problem. The
> extra signings for renumbering happen only when renumbering happens.
> 
> If we have 10000 30-day-notice MAC addresses with a 1-day-notice prefix,
> for example, and we have three renumberings over the next twenty years,
> the difference between AAAA and A6 is the difference between 2465000
> signings and 2442305 signings. Where's the 30-to-1 savings?

It's in the arithmetic, which I will do for you.  If you'll permit,
I'll round off to 360 days per year to make everything transparent.

Scenario AAAA: sign every RRset every day for 20 years.

   10,000 x 360 x 20 = 72,000,000

Scenario A6: sign the suffix RRsets 12 times a year for 20 years,
sign the one prefix RRset every day for 20 years.

   ( 10,000 x 12 x 20 ) + ( 1 x 360 x 20 ) = 2,407,200

Ratio: 29.91 to 1.

This reminds me of a previous argument.

> Put differently: You've been saying that it's painfully expensive to
> sign every record.

Some may have said that, but I didn't.

> But now you're admitting that this has to be done at least a dozen
> times every year!

You seem surprised.

> Of course, the other serious problem with your argument is that your
> one-month assumption is wrong. It is _not_ acceptable for information to
> persist for a month.

Sometimes yes, sometimes no.  With A6 you get to treat parts
differently, according to their needs.

(And to whoever it was, not Dan, I think, who said you can't override
the MAC address on some hardware: that's utterly irrelevant.  You
don't need to autoconfigure your address and even if you do, you
don't need to use only that address.)

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 25 Jul 2001 09:48:02 -0700

> Crawford wants your signatures today to last for a month.=20
> What happens if you decide tomorrow to change a machine's=20
> address list---for example, adding or removing a second address?
>=20
> Answer: An attacker can interfere with this change for 29=20
> agonizing days. All he has to do is replay the old data under=20
> the old signature.

Dan,

What you are saying is that in order to deploy DNSSEC with confidence, a
domain administrator should be ready to resign all records on short
notice; you define short as one day, but we could easily imagine the
requirement being twice a day, as suggested in one of the IPv6
scenarios. There is some aesthetical beauty to the argument, but there
is also a flip side: it follows that domain administrators should not
deploy DNSSEC if they cannot resign everyone of their records in a
flash. So, the question is, how many iterations of Moore's law do we
have to wait for until this "renumbering in a flash" becomes reality?

Let's define flash as "a few minutes." If we believe Bill Sommerfeld
experiment with the mit.edu zone, we are not quite in flash territory
yet (90 minutes for 80,000 records), but we are not very far either.
Bill used a 333 MHz Celeron laptop; a dual processor 1.7 GHz server
could arguably do the job in about 10 minutes. If we changed nothing, if
the number of hosts per zone stayed roughly constant and if the key
length did not increased, then we could be in flash territory within two
iterations of Moore's law. This means that, for reasonable zones, the
impact of cost of signature on renumbering could disappear in about 3
years.

But Moore's law will not result in a straight gain. As the computers
become more powerful, we will need to increase the key length somewhat.
As the computers become less expensive, they tend to become more
numerous, and we may find more entries in any given zone. We may just as
well be 5 years away from nirvana. In between, DNSSEC deployment will
remain clumsy, and resigning will still be perceived as an expensive
operation.

I guess looking at the issue this way helps frame the debate: 3 to 5
years from now, there won't be much practical difference, from a cost of
signing point of view, between AAAA and A6.=20

-- Christian Huitema
=20

---

From: [email-masked]
Date: Sat, 28 Jul 2001 09:36:10 -0700

Third time lucky ...

> 	Dan,
> 	     your claim is that you have to re-sign every record in
> 	a zone daily to achieve a 1 day replay window.  I'm stating
> 	that you can achieve the same protection without re-signing
> 	every record daily.
> 
> 	Pre change:
> 	example.com KEY alpha
> 	example.com SIG KEY expire=200107292257 (1 day)
> 	host.example.com A 1.2.3.4
> 	host.example.com SIG A expire=200108272257 (30 days)
> 
> 	Post change:
> 	example.com KEY beta
> 	example.com SIG KEY expire=200107072258 (1 day)

	This should have been
 	example.com SIG KEY expire=200107292258 (1 day)

> 	host.example.com A 1.2.3.5
> 	host.example.com SIG A expire=200108272258 (30 days)
> 
> 	Please explain how you can verify
> 	host.example.com A 1.2.3.4
>         host.example.com SIG A expire=200108272257
> 	after 200107292257.
> 
> 	Mark
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: [email-masked]
Date: Sat, 28 Jul 2001 09:36:06 -0700

> 
> > [email-masked] writes:
> > > there is no requirement to re-sign every record to achieve
> > > your 1 day expiry.  Just change the zone key whenever you change
> > > zone data and have a 1 day expiry on the zone key's signature.
> > 
> > No. If you maintain the validity of signatures on old records, you're
> > allowing the attack to succeed. If you don't maintain the validity of
> > those signatures, you have to immediately sign those records again.
> > 
> > Please withdraw your claim.
> 
> 	Dan,

	This should have been
 	example.com SIG KEY expire=200107272258 (1 day)

---

From: [email-masked]
Date: Sun, 29 Jul 2001 06:54:26 -0700

> You are, as I said, signing the host record again. You have to sign all
> your other records too, never mind the costs of generating and
> distributing the new key.

	Is the cost of generating a new key occasionally more or
	less than that of signing all the zone daily.  As for the
	cost of distributing the new key, it is no different to
	continue to distribute the old key apart from the cost in
	getting it signed (which is the same in both your and my
	cases).

> 
> If you change at least one of your records every day---certainly a
> reasonable assumption for the big organizations we're talking about---
> then you are signing all your records every day. The key change isn't
> accomplishing anything.

	You are making ungrounded assumptions here.  Not all large
	organizations keep everything in one flat namespace.  If
	you use the DNS as it was designed to be used you don't
	see every zone in a organization changing daily or even
	monthly (or even a large pecentage of them).

> 
> The bottom line remains the same.  Even without renumbering, you are
> signing every record every day.

	Really.  Real life has plenty of examples where existing
	zones are not changed daily.  To get 1 day replay protection
	something needs to be signed daily, however it doesn't have
	to be everything.

> If that isn't a problem, then occasional
> renumbering certainly isn't a problem. If you have one day warning, you
> can renumber for free.

	Iff your assumptions hold true.  In the real world there are
	plenty of case they don't.

> ---Dan

	Mark