Subject: Re: [dnsext] Problem with Section 2.2 of RFC 4035

From: "Jeffrey A. Williams" <[email-masked]>
Date: Tue, 17 Aug 2010 09:33:13 -0500 (GMT-05:00)

Ed and all,

I agree with Ed here as well...

-----Original Message-----
From: Edward Lewis
Sent: Aug 17, 2010 9:24 AM
To: [email-masked]
Cc: [email-masked]
Subject: [dnsext] Problem with Section 2.2 of RFC 4035

On another list, operators have identified an issue with this passage

>    "There MUST be an RRSIG for each RRset using at least one DNSKEY of
>    each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
>    itself MUST be signed by each algorithm appearing in the DS RRset

>    located at the delegating parent (if any)."

and being able to "roll an algorithm."

The problem is - what if a cache has a copy of a DNSKEY set with algorithms 5 and 7 and it receives a set only signed with algorithm 7?

(A longer winded discussion is available here:

http://dnssec-deployment.org/pipermail/dnssec-deployment/2010-August/004330.html

)

The problem I see is that validators are inappropriately enforcing the first MUST.  The MUST was for generation, not for validation.

My suggestion is to add text like this around that section (or added to the DNSSECbis document):

To clean up the specification, "it should be emphasized that although the signer is supposed to supply one of every signature, the validator only needs

one working signature to okay the data."

--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Spouses, like Internet protocols, lack necessary troubleshooting tools. Sigh.

Regards,

Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 294k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

---

From: Alfred Hönes <[email-masked]>
Date: Thu, 19 Aug 2010 21:58:01 +0200 (MESZ)

Wouter,
I agree with most parts of your detailed analysis
(http://ops.IETF.ORG/lists/namedroppers/namedroppers.2010/msg02286.html),
but the final conclusion that the DS "swap" could easily happen
in one step seems inappropriate.

Already the seminal tutorial paper from M. Rose on DNSSEC algorithm
rollover quoted earlier in this thread [*] has pointed out that
between the addition of the first "new" DS and the removal of the
last "old" DS, there will be most likely the longest period in the
whole procedure -- to be measured in years perhaps (M. Rose quotes
expected time spans of 3-6 years), so there will likely happen
multiple full (per-algorithm) rekey events in between.
This period is needed for "new" verifier releases to be deployed.
M. Rose recommends waiting for two major software update cycles
to happen for all major resolver/verifier implementations before
withdrawing the "old" DS (and subsequently the "old" key and
signatures).

The roughly four-fold DNSSEC payload in responses during rekey phases
during algorithm rollover seems to be, from an operational and
stability point of view, the most important argument for avoiding
such algorithm rollover entirely -- whenever possible, and hence
reinforcing the recommendation to start with stronger algorithms
from the beginning if you start deploying DNSSEC in a zone now,
although there might not be cryptanalytical reasons to do so.

Kind regards,
  Alfred.

[*]
http://www-x.antd.nist.gov/dnssec/download/DNSSEC_Algorithm_rollover.pdf