Subject: Re: [dnsext] Clarifying the mandatory algorithm rules

From: Samuel Weiler <[email-masked]>
Date: Thu, 10 Mar 2011 14:18:30 -0500 (EST)

On Tue, 30 Nov 2010, W.C.A. Wijngaards wrote:

> It is clear that checking the set of algorithms present in the DNSKEY
> set is not a good idea, and checking the set of algorithms from the DS
> set is the right, more lenient way to go.

I apologize for checking out of this discussion last fall.

I would like the WG's help understanding where you want to go with 
this topic.  I don't fully understand the argument in favor of not 
checking the algorithms on the child side of the zone cut (= the ones 
in the DNSKEY RRset), nor am I sure that was the direction everyone 
seemed to want to go.  Could someone summarize the current state of 
this?

My own inclination is (still) to treat this as a clarification, saying 
that validators are not required to enforce these rules.  (In other 
words, the extra checks Unbound did were just fine, though 
unnecessary.  BIND's lenient approach was also fine.)  Two specific 
pieces of proposed text can be found in the first message in this 
thread, dated 18 November 2010.

-- Sam

---

From: Mark Andrews <[email-masked]>
Date: Fri, 11 Mar 2011 09:34:38 +1100

In message <[email-masked]>, Samuel Weil
> thread, dated 18 November 2010.

While we think about this ISC has also had bug reports claiming
that is we don't publish DNSKEY prior to signing with them we are
break RFC 4035 because it allows verification of every RRSIG as a
policy and the only way to do that is to publish the DNSKEY prior
to use.

   If other RRSIG RRs also cover this RRset, the local resolver security
   policy determines whether the resolver also has to test these RRSIG
   RRs and how to resolve conflicts if these RRSIG RRs lead to differing
   results.

> -- Sam
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 11 Mar 2011 09:31:54 +0100

Hi,

On November 30, Wouter acknowledges that changes need to be made to the
Unbound implementation and asks for guidance:

  http://www.ietf.org/mail-archive/web/dnsext/current/msg10115.html

Presenting two options:
* One signature is enough (the lenient way)
* Check the algorithms.

But when checking the algorithms, thou should not use the DNSKEY RRset,
but the DS RRset.

I think the general consensus is that a validator should at least be
able to check the algorithms in the DS RRset (Please correct me if I am
being to hasty in my conclusion). There is still debate whether the
validator SHOULD or MAY do this (Ed Lewis argued the term 'could', I
think that translates to the RFC2119 term MAY).

 Proposed text would then be:

  "The validator SHOULD or MAY check (choice here) that the algorithms
   signaled in the DS-set work (but only for algorithms supported by
   the validator, of course)."

Best regards,

Matthijs

---

From: Edward Lewis <[email-masked]>
Date: Fri, 11 Mar 2011 08:34:57 -0500

"Could" as in, SHOULD NOT if I had to choose from the 2119 menu of 
options.  I'd prefer "not recommended" but that isn't on the menu.  I 
would prefer to use this bon mot: "I encourage my competitors to 
behave this way."

...to be clear, I am talking about the validator actually checking 
the signatures.  Having the ability to, sure, that is important.  But 
"if one chain works, it succeeds" is an important spirit.

At 9:31 +0100 3/11/11, Matthijs Mekking wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi,
>
>>  In message 
>><[email-masked]>, Samuel Weil
>>  er writes:
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.10 (GNU/Linux)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
>iQEcBAEBAgAGBQJNed35AAoJEA8yVCPsQCW52EcIALwitOh1IOVX6AqV28GNEYYM
>VSSlPZyVWYxD0LCVTWq5aleh3EAJ3T4BdRio795mlNrc/vLi0VNL8FqRI8U7mYk8
>I+acLNJGhoFpEFeVF+rOXpoZ3yfTerUctv1mmeyeO/2iW+PF++BJh67bcUV34h1p
>UvP3lMZCBqIpbR3uhRITjF5JsZ2yaqwoARMyIw58MM72M2Y0X3IuJCYSKSl3ANzJ
>nwBdrtZZcRmfmzJAY8PvDO0/mcyws1iK4JtiMMyXPNAfgxyBEeyxIe8YUR1yrQgL
>tcxHaDyTsaPp1GnqAbqucYWdhr17QZ1b6SUmh9qyYW1leKXZSecFUp0tjdhCYQo=
>=qOVC
>-----END PGP SIGNATURE-----

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

Me to infant son: "Waah! Waah! Is that all you can say?  Waah?"
Son: "Waah!"

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 14 Mar 2011 09:10:27 -0400 (EDT)

Thank you very much!

> think that translates to the RFC2119 term MAY).
...
>   the validator, of course)."

I understand the desire for MAY check all algorithms, and I'm fine 
with that.  (I tend to agree with Ed on SHOULD NOT, but 
whatever.)

I do not yet understand the reason for looking only at the DS RRset 
and not also the DNSKEY RRset, and I'd very much like to.

If we tell validators to that the DNSKEY RRset isn't being used for 
signalling, then presumably we're also changing what it means to be a 
"properly signed zone".  What's the new definition?  And why that 
change?

-- Sam

---

From: Edward Lewis <[email-masked]>
Date: Mon, 14 Mar 2011 09:41:41 -0400

At 9:10 -0400 3/14/11, Samuel Weiler wrote:

>then presumably we're also changing what it means to be a "properly signed
>zone".  What's the new definition?  And why that change?

Although Sam wrote this, I'm not assuming this is his opinion.

To a validator, whether or not a zone is properly signed should be 
immaterial.  A validator's concern is whether a set of data is 
properly authenticated.

The switch from "signed" to "authenticated" is on purpose, yet 
subtle.  The reason I switched is to switch from a voice of "supply 
side" to "demand side."

As a supply side'r, I'm concerned with how something is accomplished. 
Signing is one basic unit in DNSSEC.  And making sure the zone is 
properly signed is my goal.  "Properly" is relative to the 
specifications, the role of the specs is to set up expectations on 
the other side.

As a demand side'r, I'm concerned with what has been done. 
Authenticating the data is what I am achieving.  Authenticating 
involves first setting the expectation of whether I get the data I 
need (the RRSIG) and then seeing if the expectation is met.

What I am cautioning against is the degree to which a demand side'r 
goes to determine expectations.  A paranoid demand side'r almost 
looks for excuses to declare data unauthentic, and that's bad.  A 
lazy demand side'r avoids looking as much as possible, and that's 
just as bad.  A happy medium is needed.

A happy medium to me is one where the focus is goal-oriented.  If the 
data has a valid signature and I can use a chain of keys up to a 
trusted anchor, then I declare victory.  There's no security problem 
with that.

So, when it comes to validation, we should not even have a definition 
of "properly signed zone."  That is in the domain of the signer.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 14 Mar 2011 12:09:27 -0300

On Mon, Mar 14, 2011 at 10:41 AM, Edward Lewis <[email-masked]> wrote:
> immaterial.  A validator's concern is whether a set of data is properly
> authenticated.
>
> The switch from "signed" to "authenticated" is on purpose, yet subtle.  The
> reason I switched is to switch from a voice of "supply side" to "demand
> side."
>
> Signing is one basic unit in DNSSEC.  And making sure the zone is properly
> signed is my goal.  "Properly" is relative to the specifications, the role
> of the specs is to set up expectations on the other side.
>
> As a demand side'r, I'm concerned with what has been done. Authenticating
> the data is what I am achieving.  Authenticating involves first setting the
> expectation of whether I get the data I need (the RRSIG) and then seeing if
> the expectation is met.
>
> What I am cautioning against is the degree to which a demand side'r goes to
> determine expectations.  A paranoid demand side'r almost looks for excuses
> to declare data unauthentic, and that's bad.  A lazy demand side'r avoids
> looking as much as possible, and that's just as bad.  A happy medium is
> needed.
>
> A happy medium to me is one where the focus is goal-oriented.  If the data
> has a valid signature and I can use a chain of keys up to a trusted anchor,
> then I declare victory.  There's no security problem with that.
>
> So, when it comes to validation, we should not even have a definition of
> "properly signed zone."  That is in the domain of the signer.

While technically correct, I think there is a holistic concern.

All who use DNSSEC, have a vested interest in ensuring that it is, on
the whole, as secure as possible.

One facet of this is, maximizing the risk of detection of both
successful attacks, and unsuccessful attacks, on the validation side.

Observation The beauty of DNSSEC is, the data is secured (protected by
crypto signatures), so the particular source of the data (direct from
authority servers, or indirect from arbitrary caches) is irrelevant,
and so the transport doesn't need to be protected. This already
presumes that the data source (i.e. whatever server answers a query,
e.g. iterative resolver) isn't trusted per se. The presumption has to
be, that answers may be modified or replaced, somehow, by someone, and
that we are protecting ourselves from trusting those modified/replaced
answers by the protections afforded by DNSSEC. The basic problem is, a
validator cannot distinguish between incorrectly signed data (where
not all the promised algorithms have been used, "promised" == present
in the DS), and answers which have been selectively modified by an
attacker.

An attacker can either strip all but one signature, and replace that
signature with a forged signature, which matches the forged data; or
the attacker can leave now-invalid signatures along with the forged
signature and forged data.

The first level of defense, the most trivial, is the downgrade
prevention. There needs to be a proof of an answer being from an
insecure zone, before we believe an answer which has no RRSIG.

The second level of defense, the one which is not universally agreed
as necessary, is the protection against a limited substitution with a
single forged signature.

This is where the holistic approach may be a good compromise between
the believers and unbelievers (of the risk of such a signature ever
being possible):

(The following presumes more than one algorithm is in use, and thus,
that one or more algorithms now no longer has a valid signature.)

If the validation process is driven by the processing of RRSIGs, and
only indirectly checks algorithms, the first form of substitution will
go unnoticed. IMHO, this is unwise.

If the validation process is driven by first determining the
algorithms, and then checking signatures, the first form of
substitution will be detected. (See below for "what to do".)

In both cases, the second form of substitution *may* be detected,
depending on which RRSIG is checked first, and/or whether all
algorithms need to have an RRSIG successfully validated. (Also see
"what to do".)

Randomizing among the algorithms in the intersection set of "known by
the validator" and "present in the DS RRSET", ensures the probability
of detection is non-zero.

Non-zero detection is the goal -- noticing that something is up,
either because of an erroneous zone signing, or because of an attack.

What To Do

This is a question balancing the issue of false positives, with true
positives. The choices are, report "bogus", and log, or report "valid"
but log.

For sure, logging on the validator is practically mandatory, or at
least should be supported by implementers. Alerting back to the
authority server operator may or may not be appropriate to automate.

Logging by stub resolvers is not likely to be useful.

IMHO, the best choices are: randomize on algorithms, validate but log,
and have validator operators support folks (where appropriate)
investigate issues as they arise. It is probably too early to know the
rate of false positives, but that is something that operators should
likely be tracking.

The main thing is, to be able to assure would-be attackers that
*someone* will notice if/when they decide to try, and that that should
hopefully be enough of a deterrent to provide value to the whole of
the consumers of DNSSEC to justify its use.

Brian

---

From: Edward Lewis <[email-masked]>
Date: Mon, 14 Mar 2011 15:13:07 -0400

>the whole, as secure as possible.

The goal is not "as secure as possible."  Begin with DNS as it was 
defined before DNSSEC. It emphasized speed, reliability, and most 
importantly scaleable management.   DNSSEC came along to address the 
architectural vulnerability of the need for caches.  DNSSEC's target 
was to lower the gullable nature of the architecture while having as 
little impact on the original DNS as possible.

Security is never the end goal.  It is a means to an end.  The end, 
in the DNS service model, is the delivery of the answer given a 
question.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Mar 2011 08:33:19 +1100

In message <[email-masked]>, Samuel Wei
> and not also the DNSKEY RRset, and I'd very much like to.

The rule was put in there to ensure that a signer generated a zone
which had the information required for the validator to validate
the records in the zone.

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 14 Mar 2011 17:51:29 -0400 (EDT)

> which had the information required for the validator to validate

I'm lost.  Try again?  Use more words and fewer pronouns.  :-)

-- Sam

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Mar 2011 10:19:45 +1100

In message <AANLkTikKPPoJRnp_7xgxoirBhkyA2=[email-masked]>, Bri
an Dickson writes:
> >> then presumably we're also changing what it means to be a "properly sign=
> ed
> >> zone". =A0What's the new definition? =A0And why that change?
> >
> > immaterial. =A0A validator's concern is whether a set of data is properly
> > authenticated.
> >
> > The switch from "signed" to "authenticated" is on purpose, yet subtle. =
> =A0The
> > Signing is one basic unit in DNSSEC. =A0And making sure the zone is prope=
> rly
> > signed is my goal. =A0"Properly" is relative to the specifications, the r=
> ole
> > the data is what I am achieving. =A0Authenticating involves first setting=
>  the
> > expectation of whether I get the data I need (the RRSIG) and then seeing =
> if
> > the expectation is met.
> >
> > What I am cautioning against is the degree to which a demand side'r goes =
> to
> > determine expectations. =A0A paranoid demand side'r almost looks for excu=
> ses
> > to declare data unauthentic, and that's bad. =A0A lazy demand side'r avoi=
> ds
> > looking as much as possible, and that's just as bad. =A0A happy medium is
> > needed.
> >
> > A happy medium to me is one where the focus is goal-oriented. =A0If the d=
> ata
> > has a valid signature and I can use a chain of keys up to a trusted ancho=
> r,
> > then I declare victory. =A0There's no security problem with that.
> >
> > "properly signed zone." =A0That is in the domain of the signer.
> 

There is secure as possible and to strict.
 
> not all the promised algorithms have been used, "promised" =3D=3D present

Which requires the zone to be signed with a incredibly weak key or
the private key to be compromised.
 
> insecure zone, before we believe an answer which has no RRSIG.

Which the validators all do.

> as necessary, is the protection against a limited substitution with a

Which provably cannot be done with seperate DNSKEY and DATA lookups.

The only way to achieve that reliably is to return the DNSKEY RRset
along with every DATA lookup and cache the combined answer so that
the correct DNSKEY RRset can be returned with the DATA.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Mar 2011 08:45:42 -0400

>I'm lost.  Try again?  Use more words and fewer pronouns.  :-)

I'll take a stab at it.

The specification requires the generation of a signature of each 
algorithm in the DS record to set the expectation of the validator 
(remote end).  The expectation is that if the DS record set indicates 
that algorithm X is in use, there will be a signature of algorithm X 
to be had.  If this expectation is not met, then the validator is to 
declare a protocol failure.

The assumption is that, while matching down the tree (in this case 
zone by zone, not necessarily label by label), a validator is 
assessing whether there is a secure chain from a trust anchor point 
towards the target.  (In reality, this direction is in use only if 
there was no signature received.  If there was a signature, only the 
chain back is examined, no need to judge the algorithms.)  If for 
zone X there is a secure chain and the delegation to zone Y indicates 
there is a chain via an algorithm the validator understands, then 
there is the possibility of the chain extending across to Y.  If no 
algorithm in the DS set is understandable to the validator, or there 
is no DS set at all, then there is no expectation of a useable 
signature in Y, thus zone Y can be treated as unsigned.

By contradiction, let's say there was no specification of a signature 
per algorithm at each set.  In this case, the signer could sign half 
the set with one alorithm and the other half with a second.  If the 
validator only understands one of the two algorithms, a missing 
signature could be either a case of stripped data or a case or 
omission in the signing process.  Distinction between the two cases 
would be "undecidable."  ... So, we have to set a concrete 
expectation.

---

From: Casey Deccio <[email-masked]>
Date: Wed, 16 Mar 2011 11:18:26 -0700

On Tue, Mar 15, 2011 at 5:45 AM, Edward Lewis <[email-masked]> wrote:

> The specification requires the generation of a signature of each algorithm
> in the DS record to set the expectation of the validator (remote end).  The
> expectation is that if the DS record set indicates that algorithm X is in
> use, there will be a signature of algorithm X to be had.  If this
> expectation is not met, then the validator is to declare a protocol failure.
>
>
For further clarification...  It seems like you are favorable towards the
validator verifying an RRSIG for every algorithm (which it understands, of
course) that exists in the DS RRset.  Is this verification just for the
RRSIGs made by SEP (i.e., corresponding to DS RRs) DNSKEYs covering the
DNSKEY RRset, or for any arbitrary RRSIG in the zone?  If the former, once
you have authenticated the DNSKEY RRset (with all the algorithms in the DS),
then an RRSIG may be verified by any DNSKEY in the DNSKEY RRset, regardless
of algorithm; if the latter, then the algorithms must play a part in
validating any RRset in the zone.  The former seems more reasonable to me.
It seems like perhaps your view has changed from SHOULD NOT to SHOULD in one
of these regards?

In either case, I think that a bit more wording should be added to the
proposed text to make it clear what is expected of the the validator, in
terms of which RRSIG to check algorithms for, depending on what consensus
is.

Casey

---

From: Edward Lewis <[email-masked]>
Date: Thu, 17 Mar 2011 09:19:42 -0400

>"It seems like you are favorable towards the validator verifying an RRSIG
>for every algorithm (which it understands, of course) that exists in the
>DS RRset."

No, no, no, quite the opposite.  For any given resource record set, a 
validator ought to try algorithms until any one works. Same for 
signatures and keys.

I can't think of any situation in which DNS should do "everything". 
It is a "do something" protocol, not a "do everything" protocol.

The goal is "get the answer to the client" not "ensure security is followed."

Maybe the situation is unclear.

First, when obtaining an answer, DNS is mostly done as it was without 
DNSSEC, i.e., depth-first to the answer.  The "mostly" means that in 
addition to this depth-first plunge, DNSSEC records are also held.

If the answer has a signature and the answer is below a trust anchor, 
then walk backwards from the answer to the trust anchor.  That means 
starting with the answer's RRSIG's signer identifier.  Then validate 
the signer identifier and so on.  If there is ever a choice, again, 
default to a depth-first strategy to find the first chain that can be 
built.  If no chain can be built, the reason will determine if the 
situation is a service failure or an explicitly broken chain.

If the answer has no signature, then you need to first determine if 
there is a need to find one.  Starting with the appropriate trust 
anchor, go depth first towards the answer.  The dive is from zone to 
zone, looking for an unbroken chain.  If a delegation as no DS record 
set, then DNSSEC "stops."  If a delegation has a DS record set but no 
algorithm is understood by the validator, then DNSSEC "stops."  If 
the delegation has a DS record set with one algorithm that is 
understood, the next zone is signed in just that algorithm and is why 
each set has to have each algorithm.  If the delegation has a DS 
record set has a number of useable algorithms...just pick one, try 
it, if not, try another, and so on.

DNS/SEC has to have a depth-first, goal-oriented search.  It is not a 
navel-gazing, breadth-first search.  There's nothing wrong in 
pre-fetching, fleshing out the tree's trustworthiness, and other 
activity, but that shouldn't be critical path when answering a 
question.

At 11:18 -0700 3/16/11, Casey Deccio wrote:
On Tue, Mar 15, 2011 at 5:45 AM, Edward Lewis 
<<mailto:[email-masked]>[email-masked]> wrote:

For further clarification...  It seems like you are favorable towards 
the validator verifying an RRSIG for every algorithm (which it 
understands, of course) that exists in the DS RRset.  Is this 
verification just for the RRSIGs made by SEP (i.e., corresponding to 
DS RRs) DNSKEYs covering the DNSKEY RRset, or for any arbitrary RRSIG 
in the zone?  If the former, once you have authenticated the DNSKEY 
RRset (with all the algorithms in the DS), then an RRSIG may be 
verified by any DNSKEY in the DNSKEY RRset, regardless of algorithm; 
if the latter, then the algorithms must play a part in validating any 
RRset in the zone.  The former seems more reasonable to me.  It seems 
like perhaps your view has changed from SHOULD NOT to SHOULD in one 
of these regards?

In either case, I think that a bit more wording should be added to 
the proposed text to make it clear what is expected of the the 
validator, in terms of which RRSIG to check algorithms for, depending 
on what consensus is.

Casey

---

From: Casey Deccio <[email-masked]>
Date: Thu, 17 Mar 2011 08:46:35 -0700

On Thu, Mar 17, 2011 at 6:19 AM, Edward Lewis <[email-masked]> wrote:

> validator ought to try algorithms until any one works. Same for signatures
> and keys.
>
>
My apologies for the misinterpretation.  Even with the clear context of your
opinion, I somehow got lost with your opening paragraph of your example.

Casey

---

From: Edward Lewis <[email-masked]>
Date: Thu, 17 Mar 2011 12:19:07 -0400

At 8:46 -0700 3/17/11, Casey Deccio wrote:

>My apologies for the misinterpretation.  Even with the clear context of
>your opinion, I somehow got lost with your opening paragraph of your example.

Ok, again...(not frustrated that you misinterpreted, frustrated that 
I didn't remove enough pronouns)

The reason for the specification is to set the expectation of the 
validator (the receiving end).  The specification requires the signer 
(the sending end) to generate and publish at least one signature of 
each algorithm listed in the zone's DS record set.  Because of this 
rule the validator can expect that a signature by a specific 
algorithm the validator wants to use for a set of data in the zone 
will be available if listed in the DS record set.  With this 
expectation, if the validator receives a data set from the zone and 
cannot obtain a signature, then the validator is to declare a 
protocol failure.  The validator does not need the other signatures, 
therefore should not waste time evaluating them.  These other 
signatures might be important to other validators.

What I didn't explain this time is why the DS record set is important 
to all of this.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Casey Deccio <[email-masked]>
Date: Fri, 18 Mar 2011 09:36:51 -0700

On Thu, Mar 17, 2011 at 9:19 AM, Edward Lewis <[email-masked]> wrote:

> The reason for the specification is to set the expectation of the validator
> (the receiving end).  The specification requires the signer (the sending
> end) to generate and publish at least one signature of each algorithm listed
> in the zone's DS record set.  Because of this rule the validator can expect
> that a signature by a specific algorithm the validator wants to use for a
> set of data in the zone will be available if listed in the DS record set.
>  With this expectation, if the validator receives a data set from the zone
> and cannot obtain a signature, then the validator is to declare a protocol
> failure.

Okay, so the signer sets the expectation of the validator using the
algorithms in the DS RRset.  Now, does this expectation hold for simply
authenticating the DNSKEY RRset or for all zone data?

For example:

- DS RRset has only algorithm 5
- DNSKEY RRset signed by a DNSKEY matching the DS (alg 5)
- DNSKEY RRset contains DNSKEYs with algs 5 and 3
- DNSKEY with alg 3 signs A RRset.

Is there a valid chain to the A RRset, or is it a protocol failure?
Following the principle of "if one chain works, it succeeds", I would say
that it is valid.  But it's unclear whether this is part of the expectation
of the signer for the validator, and even the paragraph quoted above seems
to declare it a protocol failure--although I well understand your position
on principle.  Whether it is valid or not, I believe it should be worded
explicitly to avoid ambiguity and accurately convey principle.

Casey

---

From: Edward Lewis <[email-masked]>
Date: Fri, 18 Mar 2011 12:59:17 -0400

At 9:36 -0700 3/18/11, Casey Deccio wrote:

>algorithms in the DS RRset.  Now, does this expectation hold for
>simply authenticating the DNSKEY RRset or for all zone data?

No, the specification sets expectations.  I don't mean to be a pain, 
but the first words say this: "The reason for the specification is to 
set the expectation."  I mean that in the strictest sense.  The 
validator knows there's supposed to be X because the spec says so.

>Is there a valid chain to the A RRset, or is it a protocol failure?

Depends.  If the validator knows both 3 and 5, then it can build a 
chain and it's cool.  If the validator only knows 5, then there's a 
missing piece.  If the validator only knows 3, there's no chain to 
the data.

In summary:
Validator knows 3 & 5 - validates
Validator knows only 3 - data is accepted as not-signed.
Validator knows only 5 - service failure as *expected* signature is not found*
Validator doesn't to 3 & 5 - accepted as not-signed
Validator doesn't do DNSSEC - accepted as not-signed

*not found = not obtainable, can't get it, ...

>on principle.  Whether it is valid or not, I believe it should be
>worded explicitly to avoid ambiguity and accurately convey principle.

It is always up to the validator to decide if it accepts the data. 
Local policy and DNSSEC is about protecting the cache.  DNSSEC is NOT 
designed to enforce proper operations, it is NOT to force the zone 
admin into doing anything.  Remember, DNSSEC is optional to the 
protocol, it's the validators that want to pull the data for 
protection.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 18 Mar 2011 13:07:44 -0400

I should add...just because "there's supposed to be X" doesn't mean X 
has to be there.  If I'm looking for X and it's not there, we have a 
failure.  If I'm not looking for X and it is not there, "no harm, no 
foul."  (The latter is the same as not needing X and it's there 
anyway.)

At 12:59 -0400 3/18/11, Edward Lewis wrote:
>but the first words say this: "The reason for the specification is 
>to set the expectation."  I mean that in the strictest sense.  The 
>Local policy and DNSSEC is about protecting the cache.  DNSSEC is 
>NOT designed to enforce proper operations, it is NOT to force the 
>zone admin into doing anything.  Remember, DNSSEC is optional to the

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 30 Mar 2011 22:04:19 +0200

Ok, so let's try to come to a reasonable clarifying text:

- -------------------------------------------------------------------------
Section ?.? Clarifying the validators interpretation regarding multiple
algorithms.

RFC 4035, section 2.2 talks about Zone Signing. It mentions that

 "There MUST be an RRSIG for each RRset using at least one DNSKEY of
  each algorithm in the zone apex DNSKEY RRset".

This is a requirement at the server side, not the client side. In other
words, when a validating resolvers is in the process of validating a
RRset, it SHOULD NOT expect a RRSIG of each algorithm that is in the
zone apex DNSKEY RRset.
- -------------------------------------------------------------------------

This only fixes the misinterpretation on the expectation a validator may
have. It does not deal with algorithm downgrade protection at all (as
some may believe does not exist in DNSSEC). If there is need for
clarifying algorithm downgrade protection, or its non-existence, I
suggest something in the line of:

- -------------------------------------------------------------------------
Section ?.? Algorithm downgrade protection.

The validator could check that there are RRSIG records for each RRset
using at least one DNSKEY of each algorithm in the DS RRset, published
in the parent zone. This ***

*** Choice here
- - is however NOT RECOMMENDED. ['the one signature is enough approach']
- - is OPTIONAL. ['leave the choice to the implementation' approach]
- - is RECOMMENDED behavior. ['algorithm downgrade protection' apprpach]
- -------------------------------------------------------------------------

Best regards,

Matthijs

On 03/18/2011 06:07 PM, Edward Lewis wrote:
> foul."  (The latter is the same as not needing X and it's there anyway.)
> 
>> missing piece.  If the validator only knows 3, there's no chain to the
>> data.
>>
>> In summary:
>> protocol, it's the validators that want to pull the data for protection.
>>
>> --

---

From: Edward Lewis <[email-masked]>
Date: Thu, 31 Mar 2011 15:03:32 -0400

Ironically, I was thinking about this issue when the mail came in yesterday.

>Ok, so let's try to come to a reasonable clarifying text:

That's not right either, unfortunately, I want to avoid "SHOULD NOT 
expect" in the text.  How about trying this for the last part of the 
last sentence.

...it SHOULD expect to find an RRSIG of *any* algorithm that is in 
the zone apex DNSKEY RRset.  As a validator ought to be satisfied in 
building one chain of trust acceptable to local policy, a validator 
SHOULD NOT check that all signatures are received.  Doing so 
represents a distraction from the goal of returning an answer 
swiftly.  A validator MAY have a configuration option to perform a 
signature completeness test to support troubleshooting.

The *any* there is important, but not the *'s.  I added them to 
stress the "any."

>suggest something in the line of:

NOT RECOMMENDED, I consider it unnecessary work towards the goal of 
finding what the client asked for.  That is, in a default setting. 
The principle that I am pinning this on is that one of the strengths 
of the DNS protocol is a fast response.

>iQEcBAEBAgAGBQJNk4zDAAoJEA8yVCPsQCW502MH/0unZXAo8KqLpwDrXbBBaGps
>5rm7eA6rgipU1y99QOMZOggzu5XsI3VVZq8LiTIzKgBB69iufN392v/4afWiEgcW
>LGdETtYwQmaif+Rj7+3UhjbSFJj7h2yPUlDvFoT66YOr7HaV+Ow9niYSnTbxmZgV
>L/AWNjdpMsfmFoxk9OfJZlYnfgPA2gK4UyUG5YduwybeW1REcqyoQ3V73HnkhZod
>SZ5QDHp/mRj4JjlACwSPSg5cQO1hURfp4r43oad0mO2Y1p2cjknp/cF9kcgI2VQu
>bBSQ+0oEz55N/8yqzKznfY9tsUWwfsnBmjkMyA8mKD9BuzstScCvXs71K1Dz3SM=
>=vrOn

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 31 Mar 2011 22:08:11 +0200

On 03/31/2011 09:03 PM, Edward Lewis wrote:
> -
> -------------------------------------------------------------------------
> -
> -------------------------------------------------------------------------
> 
>> ...it SHOULD expect to find an RRSIG of *any* algorithm that is in the
>> zone apex DNSKEY RRset.  As a validator ought to be satisfied in
>> SHOULD NOT check that all signatures are received.  Doing so represents
>> a distraction from the goal of returning an answer swiftly.  A validator
>> MAY have a configuration option to perform a signature completeness test
>> to support troubleshooting.

I would than say "it can expect to find" (not make it a rfc 2119 term)

> 
>> The *any* there is important, but not the *'s.  I added them to stress
>> the "any."
> 
> -
> -------------------------------------------------------------------------
> - is however NOT RECOMMENDED. ['the one signature is enough approach']
> - is OPTIONAL. ['leave the choice to the implementation' approach]
> - is RECOMMENDED behavior. ['algorithm downgrade protection' apprpach]
> -
> -------------------------------------------------------------------------
> 
> 
>> finding what the client asked for.  That is, in a default setting. The
>> principle that I am pinning this on is that one of the strengths of the
>> DNS protocol is a fast response.
> 
> 
> Best regards,
> 
> Matthijs
> 
> 
>