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

From: Matt Crawford <[email-masked]>
Date: Fri, 20 Jul 2001 15:05:00 -0500

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

The reason is security, in that you can't make the record go away
until the signature becomes invalid.  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.

(Yes, a day is awfully short for a non-mobile site, but awfully long
for a mobile one.)

---

From: "D. J. Bernstein" <[email-masked]>
Date: 21 Jul 2001 04:14:22 -0000

Matt Crawford writes:
> So if it's all right for your

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?

Put differently: You've been saying that it's painfully expensive to
sign every record. But now you're admitting that this has to be done at
least a dozen times every year!

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. I addressed this in my previous message, and in my
``Extremely long TTLs'' message six months ago. I'm not sure why you've
waited six months to state your disagreement.

---Dan

---

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

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

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

> 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: David Terrell <[email-masked]>
Date: Mon, 23 Jul 2001 14:00:44 -0700

> waited six months to state your disagreement.

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

-- 
David Terrell            | "My question is, if a mime types, isn't 
[email-masked]             |  that kinda cheating?"
http://wwn.nebcorp.com/  |    - Jason Zych

---

From: "D. J. Bernstein" <[email-masked]>
Date: 25 Jul 2001 12:35:28 -0000

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.

> 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

---

From: Robert Elz <[email-masked]>
Date: Fri, 27 Jul 2001 18:00:03 +0700

Date:        Wed, 25 Jul 2001 06:28:32 -0700
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | 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

---

From: Robert Elz <[email-masked]>
Date: Fri, 27 Jul 2001 18:00:03 +0700

| What happens

  | Renumbering

kre

---

From: Robert Elz <[email-masked]>
Date: Fri, 27 Jul 2001 18:00:03 +0700

| What happens

  | Renumbering

kre

---

From: [email-masked]
Date: Sat, 28 Jul 2001 17:31:20 +1000

> [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,
	     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)
	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: "D. J. Bernstein" <[email-masked]>
Date: 28 Jul 2001 06:08:23 -0000

---Dan

---

From: [email-masked]
Date: Sat, 28 Jul 2001 10:36:38 +1000

Dan,

	So daily you re-sign two RRsets. 

	Mark

---

From: "D. J. Bernstein" <[email-masked]>
Date: 29 Jul 2001 12:14:24 -0000

> 	host.example.com SIG A expire=200108272258 (30 days)

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.

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.

The bottom line remains the same. Even without renumbering, you are
signing every record every day. 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.

---Dan

---

From: [email-masked]
Date: Sun, 29 Jul 2001 23:26:07 +1000

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

> then you are signing all your records every day. The key change isn't

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

> 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

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

	Mark

---

From: "D. J. Bernstein" <[email-masked]>
Date: 29 Jul 2001 13:57:07 -0000

Robert Elz writes:
> 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.

How, pray tell, do you expect a large site to sign its DNS records, if
it has access to its signing key only twelve times a year?

This is even worse than ``wait a month for old records to go away.'' It
also means ``wait a month for new records to appear.'' Do you seriously
believe that administrators and users will tolerate this?

---Dan

---

From: Robert Elz <[email-masked]>
Date: Tue, 31 Jul 2001 19:21:26 +0700

Date:        Mon, 30 Jul 2001 11:55:29 -0700
    From:        Olafur Gudmundsson/DNSEXT co-chair <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	51 IETF DNSEXT NGTRANS Joint Meeting on
  | 	IPv6 Addresses in DNS
  | 
  | 	Monday 2001/Aug/6   15:30-17:30
  | 	Room: King's Suite/Balmoral 2

I'm not going to be there, and thus didn't write a draft to speak about
at the meeting (which the earlier request seemed to be about).

I will make some comments about the 5 drafts (well, 4 drafts and a web
page) that are to be considered though.

Before I begin, I'd like to point out again that this issue really has
nothing whatever to do with ngtrans - it should be being considered in
the ipngwg rather than ngtrans.  This issue has nothing specifically to
do with transition arrangements (other than that a solution is needed
so the transition can happen - but that is or was true of everything else
related to IPv6 - the basic protocol doc might just as well have been
done in ngtrans if that was the criteria).

ngtrans should be concerning itself with those short term issues needed
to allow the v4 internet to turn itself into the v6 internet.   The result
when that has finished should be what has been defined by the ipngwg,
all the ngtrans issues should eventually simply vanish (eventually may
be a long time away, that's OK).

Nor is this really a dnsext issue - when the RR types were being defined
that made sense, but it doesn't really any more.   The question is just
which RR type (which exists in the DNS definitions already) IPv6 should
actually be using (not for the transition period, but forever).

Once that decision is made, if ngtrans wants to map a path to get from
where we are now, to the eventual end point, that's fine.   But it really
is a bit hard for ngtrans to plan a transition when the end point isn't
yet fixed.

  | 1 Rob Austein:
  |   <http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt>

This is an excellent analysis of the issues.   (It also makes the point
that this is really an ipv6 issue - ipngwg that is).

About the only issue I have with it is the assumption that whether to
use AAAA or A6 should be decided merely by the relative frequency of
renumberings expected for IPv6 systems.

One reason for not simply going that way, is that it is an issue upon
which no-one really agrees.   There are hopes, expectations, and
dooms day scenarios, which all produce different expectations.

Personally I have no idea how frequently IPv6 nets will renumber.  What
I am sure of however, is that I want to do everything possible to allow
for renumberings to happen with the greatest possible ease, with the
smallest possible notice, and the greatest possible frequency.   Planning
that way maximises the chances that we will actually end up with something
which will work in the environment that develops - whether that means
permanent addresses, and no renumbering at all for anything (ie: we manage
to make the routing system deal with routing to arbitrary /128's), or
if we end up in a state where major sites are expected to renumber
four times a day as traffic patterns shift going to and from the work
user and home user peak periods.

  | 2 Christian Huitema:
  |   <http://www.ietf.org/internet-drafts/draft-huitema-ipv6-renumber-00.txt>

This is just a summary of what's involved in renumbering in some
interesting cases.  The draft is fine, but I'm not sure it adds a
whole lot to the A6 vs AAAA debate.

  | 3 Matt Crawford:
  |   <http://home.fnal.gov/~crawdad/draft-ietf-dnsext-ipv6-dns-response-00.txt>

I have nothing much to say about this one, other than that I essentially
agree with all of it.

  | 4 Jun-ichiro itojun Hagino <[email-masked]>:
  |   <http://www.ietf.org/internet-drafts/draft-ietf-dnsext-aaaa-a6-01.txt>

This one contains a bunch of info on the current state of the world,
followed by a large amount of FUD.   There's essentially nothing in it
of value to the discussion.  I could analyse this doc paragraph by
paragraph, and was once planning to do so - but I think that would be
a waste of everyone's time.

  | 5 Dan Bernstein:
  |   <http://cr.yp.to/djbdns/killa6.html>

And this one points out that with A6 it will be possible for sites to
create ludicrous setups that won't work.   Without A6 sites can create
ludicrous setups that won't work, so there is nothing really new here.
Just one extra way to shoot yourself in the foot.  Big deal.

What is missing in all of this is any real data upon which anyone could
really base a decision.   There's no comparisons of how many queries
it will take to resolve names in various common cases, what the cache
effectiveness can be expected to be, how much cache churn renumbering
will cause, how big the DNS packets for various scenarios will actually
be - nothing like this at all.

The effect of that is that any decision on which way to go cannot be
based upon any more than either guesswork or fear.

I had hoped to have collected some data on all of this by now, but for
various reasons it hasn't happened yet (even if it had, there wouldn't
have been very much yet, so it probably still would have been premature
to use it for much).

I am still planning to (ie: actually doing the setup for now) collect
some data, initially on A6 vs AAAA - that is, so see whether any extra
round trips that are needed actually make a difference to name resolution
for rationally configured setups (I'll also look at some irrational
configurations of course).

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 31 Jul 2001 23:15:27 -0000

Robert Elz writes:
> create ludicrous setups that won't work.

In the aol.com example, the sysadmin sets up dns-01.ns.aol.com A6 ...
prefix.aol.net, and similarly dns-02.ns.aol.com A6 ... prefix.aol.net.
What's ``ludicrous'' about that? It's exactly what the A6 specifications
encourage him to do. But it destroys connectivity to AOL.

All the efficiency issues are minor. The reliability issues are crucial.
The A6 proponents keep claiming that a limited form of A6 is safe, but
they never answer when I ask them to identify the exact limitation that
has this magical effect. How is the DNS administrator supposed to tell
the difference between ``ludicrous'' A6 records and normal A6 records?

> Without A6 sites can create ludicrous setups that won't work, so there
> is nothing really new here.

My web page explains three ways that A6 and DNAME lead to problems.
``These problems are not new,'' it says. But it then explains why the
problems are under control now, and why they will spiral out of control
with A6 and DNAME. My web page also analyzes the alleged benefits of A6
and DNAME.

---Dan