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

From: Matt Crawford <[email-masked]>
Date: Fri, 20 Jul 2001 11:59:48 -0500

> 2. There's a common error in the evaluation of DNSSEC signing costs. I'd
> like to draw attention to a new section that I've added to my web page
> to analyze this error: http://cr.yp.to/djbdns/killa6.html#signingcosts

Your reasoning is markedly incorrect if applied to A6.  If we take
site renumbering to be the dominant factor controlling
signature-validity times, then the signatures on the A6 records
covering interface identifiers and subnets can be valid for a long
time, and only one or a small number of A6 rrsets covering the global
prefixes needs to be re-signed frequently.

> 3. I don't understand why this is an ngtrans issue rather than an ipngwg
> issue. The question is not how to move smoothly to A6/DNAME; the
> question is whether we want A6/DNAME at all.

On this we agree.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Sat, 21 Jul 2001 02:18:45 +0900

>signature-validity times, then the signatures on the A6 records

	from what I got from reading djb's webpage, djb's point is that
	the dominant factor controlling signature-validity time is security,
	and for that reason he claims it needs to be very short (so there's
	no real difference in signing overhead for AAAA or A6).  so the
	assumption for the "dominant factor" is totally different between
	you two.

	i'm still not sure if djb's claim is right or not, but anyway
	that's what i got from his note.

itojun

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Jul 2001 22:13:22 -0000

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

This applies to _all_ records. Existing DNS software assumes, correctly,
that long TTLs are a mistake. I elaborated on these points in an
``Extremely long TTLs'' message on ipng in January:

   Everything changes. Machines acquire extra IP addresses. Machines
   disappear. Even MAC addresses change: network cards die. (It isn't
   always possible, never mind easy, to reprogram the MAC address on the
   new card.)
   
   Those of us who write caches don't want to deal with users asking ``why
   am I getting the old address?'' when a novice administrator starts with
   a silly 6-week TTL and then suddenly realizes that he has to change the
   address. My cache never saves data for more than a week.

Yes, the average address stays unchanged for a very long time. Yes, it
might stay unchanged for even longer with A6. But that's not what TTLs
measure! When an address _does_ have to be changed, there's often not
much warning. _That_ is what TTLs are for.

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.

---Dan

---

From: Matt Crawford <[email-masked]>
Date: Sun, 22 Jul 2001 14:17:35 -0500

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

> 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.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------