Subject: [dnsext] Validator assumptions: what algorithms need to properly sign a zone?

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 23 Mar 2012 11:42:03 -0400

Following configuration was detected in the wild recently:
Notation: A is algorithm x
	  B is algorithm y
	  An is key n of algorithm A

Parent:
	DS   1 A1
	DS   2 A1

Child:
	DNSKEY A1,B1      signed by A1 and B1
	SOA               signed by A1 and B1
	all other records signed by A2 and B1

Notice that A2 signs records w/o being in the DNSKEY RRset.

Some validators returned AD others return SERVFAIL for the RRsets signed 
by A2 + B1.
The validators that return AD make the jump from algorithm A to B when 
validating the zone, the ones that SERVFAIL expect that the zone be 
properly signed by algorithm A (which it is not).

Both positions are arguable, but it is bad for resolver vendors to be 
put in this position to argue with customers why they disagree on the 
right answer, and DNSSEC operators need a strong message what is allowed.

In the case of a validator that supports A but not B SERVFAIL is the 
right answer as the zone is not properly signed for that algorithm.
In this particular case the validators supported both algorithms.

Background:
The zone seems to be in compliance with the list in RFC4035 section 2.2 
i.e. there exists a valid signature by a key in the DNSKEY RRset.
But in the final paragraph that seems to be contradicted and does
require the a signing key for all algorithms to be in the DNSKEY RRset.

Section 5.4 of dnssec-bis seems skirts on this issue.
Section 5.11 of dnssec-bis seems to strongly say that any algorithm in 
the DNSKEY should work:
     without saying what to do if not all the algorithms are supported
or  that at least one algorithm in the DS MUST work.

Some people in this working group have argued that use/order of 
algorithms should be local policy and it is outside the documents scope 
to talk about this, others argue that will lead to unpredictability in 
resolution status.

Fundamental question:
What algorithms can a validator use to validate records from a zone 	
   1) only algorithms in DS RRset
   2) any algorithm in the validated DNSKEY RRset

Doodle poll available at:
	http://www.doodle.com/7v5vmzvaerb2n8sb

Please fill in the poll, chairs will judge if any changes are needed in 
DNSSECbis.

	Olafur

---

From: Samuel Weiler <[email-masked]>
Date: Fri, 23 Mar 2012 14:13:16 -0400 (EDT)

Reordering Olafur's message.

>  2) any algorithm in the validated DNSKEY RRset

I'm not sure how you got to that as the final question, but it's an 
easy one to answer: #2.  We decided to have algorithm signalling 
happening in BOTH the DS RRset and the DNSKEY RRset.  The DNSKEY RRset 
can add algorithms but not remove them.

It sounds like what you're trying to ask, though, is "MUST a resolver 
try all algorithms, even to the point of jumping between algorithms?". 
bis-updates 5.4 says SHOULD, not MUST, without explictly saying 
anything about jumping between algorithms.

There is going to be unpredictability in this case.  Some resolvers 
won't support B, whether through implementation choice or 
configuration choice (B might be weak, hence turned off).  And it's 
probably sane, though certainly not necessary, for a validator to 
impose a no-alogrithm-jumping rule.  Hence limiting 5.4 to a SHOULD, 
not a MUST.

> 	http://www.doodle.com/7v5vmzvaerb2n8sb

A Doodle poll seems like a poor tool for something such as this.

> Section 5.11 of dnssec-bis seems to strongly say that any algorithm in the 
> DNSKEY should work:

Both this and 4035 section 2.2 may not explicitly say "and the chain 
of trust has to work within each algorithm".  Is that not said or 
implied elsewhere?  Are these sections really so ambiguous that we 
need to clarify them?

Please re-read bis-updates 5.11 and ponder.

-- Sam

---

From: Samuel Weiler <[email-masked]>
Date: Fri, 23 Mar 2012 14:17:39 -0400 (EDT)

On Fri, 23 Mar 2012, Samuel Weiler wrote:

> There is going to be unpredictability in this case.  Some resolvers won't
> support B, whether through implementation choice or configuration choice (B 
> might be weak, hence turned off).  And it's probably sane, though certainly 
> not necessary, for a validator to impose a no-alogrithm-jumping rule.  Hence 
> limiting 5.4 to a SHOULD, not a MUST.

And I should clarify: there is going to be unpredictability because 
the zone is not properly signed.  The chain of trust in alg A is 
broken.

-- Sam

---

From: Tony Finch <[email-masked]>
Date: Fri, 23 Mar 2012 18:23:49 +0000

Olafur Gudmundsson <[email-masked]> wrote:
>
> The zone seems to be in compliance with the list in RFC4035 section 2.2 i.e.
> there exists a valid signature by a key in the DNSKEY RRset.

I believe the consensus is that that requirement applies to the signer
not the validator.

>   2) any algorithm in the validated DNSKEY RRset

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Portland: Mainly easterly 3 or 4, occasionally 5 later. Smooth or slight,
occasionally moderate later. Fog patches. Good, occasionally very poor.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 23 Mar 2012 17:06:40 -0400

On 23/03/2012 14:23, Tony Finch wrote:
> Olafur Gudmundsson<[email-masked]>  wrote:
>>

but the validator needs to take into account what the signer is 
allowed/required to do we cannot have totally disjoint 
requirements/assumptions.

	Olafur

---

From: Mark Andrews <[email-masked]>
Date: Mon, 26 Mar 2012 11:37:47 +1100

> requirements/assumptions.

We don't have disjoint requirement.  The DS records / configured
trust anchors for the zone set up a expection for the zones contents
by listing the algorithms that are expected to work.  The signer
meets those expections by ensuring that each RRset is signed as
described.  This takes in to account the affects of caching associated
with introducing new signing algorithm to a zone.

It is NOT the signers job to check that every RRSIG set contains
every algorithm listed in the DNSKEY RRset as the contents of these
can and often will be from different versions of the zone signed
at different times.  If the validator is paranoid it MAY check every
algorithm listed in the DS RRset/trust anchors is present and it
MAY ignore algorithms not in the DS RRset/trust anchors.

The validator however MUST NOT check that every algorithm listed
in the DNSKEY RRset is present in every RRSIG set.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Mon, 26 Mar 2012 11:56:08 +1100

In message <[email-masked]>, Mark Andrews writes:
> i.
> > e.
	s/signers/validator's/
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

---

From: Edward Lewis <[email-masked]>
Date: Mon, 26 Mar 2012 11:43:47 +0200

At 11:42 -0400 3/23/12, Olafur Gudmundsson wrote:

>Both positions are arguable, but it is bad for resolver vendors to 
>be put in this position to argue with customers why they disagree on 
>the right answer, and DNSSEC operators need a strong message what is 
>allowed.

I disagree.  There should be no argument.  A validator needs to be as 
liberal as possible in building a secure "chain" to a trust anchor. 
Liberal means using as many valid options as possible including 
jumping algorithms.  Liberal does not mean bending the rules, 
accepting invalid signatures nor accepting expired signatures.

The reason for the need to be liberal is that DNSSEC is an "add on" 
which inherently makes the underlying system more brittle.  By 
declaring once valid states of the DNS protocol to be dead states 
(SERVFAIL) DNSSEC is choking off parts of the protocol.  To correct 
for that, at least in the name of reliability, resiliency, and 
availability, DNSSEC has to be as liberal (rugged is another word) as 
possible.

Looking at the example, the A2 signatures would be consider not 
germane by any validator that lacks an A2 trust anchor that was the 
key doing the A2 signing.  The lack of A1 signatures would mean any 
validator could rightly assume that something removed the signatures 
("rightly assume" is not equal to "be right in assuming") and treat 
the response as suspect/invalid *if not* for the presence of a valid 
chain via the B1 algorithm.

A valid chain is harder to construct that an invalid one.  Make it it 
harder for a malicious agent by recognizing that fact.  Don't make it 
trivial to cause a denial of service.

>right answer as the zone is not properly signed for that algorithm.

That is true.  In this case, the validator's failure to speak 
algorithm B is a testament to a lack of ruggedness.

>Some people in this working group have argued that use/order of algorithms
>should be local policy and it is outside the documents scope to talk about
>this, others argue that will lead to unpredictability in resolution status.

Everything is trumped by local policy.  And if local policy is not 
rely on an algorithm, that is a fact of life.   DNSSEC does not 
guarantee the data will get though, it guarantees that is what is 
received can be tested.  (Positive, validation isn't guaranteed, just 
that the receiver will have the means to test.)

>	http://www.doodle.com/7v5vmzvaerb2n8sb

Filled in the poll, but still reject voting. ;)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!

---

From: Tony Finch <[email-masked]>
Date: Mon, 26 Mar 2012 11:00:39 +0100

Olafur Gudmundsson <[email-masked]> wrote:
> > > i.e.

They aren't disjoint. I think it makes more sense if who takes what into
account is the opposite way round to what you suggest. The validation
algorithm allows for a lot of flexibility and makes validation possible
despite some kinds of brokenness; the requirements on the signer keep it
well within the range of what validators allow. Robustness principle.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fisher, German Bight: Northwesterly 3 or 4, increasing 5 or 6 in east Fisher.
Moderate in east Fisher, otherwise slight. Fog patches. Moderate or good,
occasionally very poor.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 26 Mar 2012 12:55:22 +0200

>well within the range of what validators allow. Robustness principle.

Yup.