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

From: Edward Lewis <[email-masked]>
Date: Fri, 1 Apr 2011 08:04:59 -0400

That's a good change.  Yep, it isn't "specification language worthy."

At 22:08 +0200 3/31/11, Matthijs Mekking wrote:
>
>I would than say "it can expect to find" (not make it a rfc 2119 term)
>

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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!"
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Samuel Weiler <[email-masked]>
Date: Fri, 1 Apr 2011 10:21:58 -0400 (EDT)

As in my last message, Matthijs, Mark Andrews, and I spent some time 
today trying to understand each other.  This is the first of three 
posts trying to capture our understandings.

I believe we're in agreement about the mandatory algorithm rules in
rfc4035 and the general direction in which they should be clarified.
There are two proposals for changing these rules, which I'm describing
in separate notes.  I think we should resolve both now so that we only
have to make the clarification once.  Please respond to each of those
notes separately with your opinions on each.

I'll restate the current (clarified) rules here, though the actual
clarification text will probably look more like what I posted in
November.  Think of this more as a starting point for considering the
two proposals that follow than as final text to be added to
dnssec-bis-updates.

    The DS RRset and DNSKEY RRset are used to signal which algorithms
    are used to sign a zone.  The pressence of an algorithm in a zone's
    DS or DNSKEY RRset set signals that that algorithm is used to sign
    the entire zone.

    When signed, a zone MUST include a DNSKEY for each algorithm
    present in the zone's DS RRset and expected trust anchors for the
    zone.  The zone must also be signed with each algorithm (though not
    each key) present in the DNSKEY RRset.  It is possible to add
    algorithms at the DNSKEY that aren't in the DS record, but not
    vice-versa.

    [The above is all clarification -- the below is arguably a change,
    and it's one that would itself be changed by proposal #1.]

    These rules, an indicated by their pressence in second 2 of 4035,
    are rules for zone singers, not rules for validators.  Validators
    SHOULD accept any single valid path.  They SHOULD NOT insist that
    all algorithms signalled in the DS RRset work, and they MUST NOT
    insist that all algorithms signalled in the DNSKEY RRset work.

---

From: Samuel Weiler <[email-masked]>
Date: Fri, 1 Apr 2011 10:24:45 -0400 (EDT)

This is a proposed change in DNSSECbis that arguably changes the 
mandatory algorithm rules.  I'm posting this as a summary of what I 
understand some may support, I don't support this change myself. 
Please post in this thread with your support or lack thereof.

In order to provide some protection against algorithm downgrade[1], 
we're defining a mechanism for zone signers to signal to validators 
that a SET of algorithms should ALL be checked, when possible, before 
determining that an answer from the zone is Secure.  Specifically, 
we're overloading the DS RRset to do that signalling.

Validators SHOULD check signatures from all algorithms present in a 
zone's DS RRset or trust anchors before declaring an answer from the 
zone to be Secure.  If it is impossible to validate an answer with one 
or more of those algorithms, the answer SHOULD be treated as Bogus.

This is a subset of the checks unbound was performing that let to the 
discovery of the problems with .cz's algorithm roll process.

Please post in this thread with your support or objections.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Samuel Weiler <[email-masked]>
Date: Fri, 1 Apr 2011 10:26:28 -0400 (EDT)

On Fri, 1 Apr 2011, Samuel Weiler wrote:

> In order to provide some protection against algorithm 
> downgrade[1]...

I forgot to provide the footnote in my first message:

[1] Acknowledging that some algorithms may eventually become weak, but
such weaknesses may not be as clear and binary as "yesterday the
algorithm was secure and today it is totally broken", a zone signer
might wish to provide signatures from a more secure algorithm so that
newer validators can be protected while simultaneously providing older
(weak) signatures for the benefit of validators that have not been
upgraded.  Without a signaling mechanism such a this, a validator
supporting both old and new algorithms may find itself accepting
forged answers signed only with the old (and broken!) algorithm.

Alternatives to this mechanism include disabling the broken algorithm
in the validator (which could unnecessarily prevent validation of
zones that haven't signed with something stronger) or implementing a
preference system in the validator (e.g. "if the zone is signed with
WeakAlgA and StrongAlgB, ONLY check the signatures from StrongAlgB").

---

From: Samuel Weiler <[email-masked]>
Date: Fri, 1 Apr 2011 10:28:15 -0400 (EDT)

This is a proposed change in DNSSECbis that changes the mandatory 
algorithm rules.  I'm posting this as a summary of what I understand 
some may support; I don't support this change myself. Please post in 
this thread with your support or lack thereof.

For additional operational and zone-signing flexibility, particularly
to allow the publication of a DNSKEY of a new algorithm before a zone
is fully signed with that algorithm, we propose to change these rules
to use ONLY the DS RRset for algorithm signalling, not the DNSKEY
RRset.

Zones will be required to be signed with each algorithm (though not
necessarily eack key) present in the zone's DS RRset or configured
trust anchors.

My opinion:

In retrospect, we probably could have used this mechanism when we 
first wrote these rules -- the choice to use both DS and DNSKEY for 
signalling may have been an artifact of history.  As it is, this 
change may cause zones signed under these new rules to fail validation 
in deployed code, including unbound.  That alone is enough to lead me 
to oppose this change.

-- Sam

---

From: Edward Lewis <[email-masked]>
Date: Fri, 1 Apr 2011 10:53:09 -0400

At 10:24 -0400 4/1/11, Samuel Weiler wrote:
>that a SET of algorithms should ALL be checked, when possible, 
>before determining that an answer from the zone is Secure. 
>Specifically, we're overloading the DS RRset to do that signalling.
>
>zone to be Secure.  If it is impossible to validate an answer with 
>one or more of those algorithms, the answer SHOULD be treated as 
>Bogus.
>
>This is a subset of the checks unbound was performing that let to 
>the discovery of the problems with .cz's algorithm roll process.
>

IMHO, algorithm downgrade protection is not a goal of DNSSEC. 
Further, there is no way an algorithm downgrade attack can succeed.

Presuming validation, when a resolver receives an answer section 
containing an RRset matching it's query, a resolver has to determine 
if the data is known to be insecure or is supposed to be secured.

If a signature arrives with the answer, the validator can begin there 
and work towards a trust anchor.  Recalling that the point is cache 
protection and the decisions made by the validator are governed first 
and foremost by local policy a validator can decide to ignore a 
specific algorithm as being suspect or broken.

If we are working backwards - that is up the tree from the answer to 
a trust anchor or forward - from a trust anchor down to the answer, 
there will be a point in which we can get the DS RRset for a zone cut 
from a parent and verify it completely.  In the DS set are the set of 
algorithms available of the zone below for the verifier to reply 
upon.  Again, it's the verifiers call which algorithms to use, not 
the DS set.

 From this the verifier can validate the DNSKEY set of the zone cut's 
corresponding apex.  The reason it can do this is that it has secured 
the DS set's state.  If there is no DS set, then there is an empty 
set of algorithms.  If the DS set has no algorithms useful to the 
validator, empty set.  If the DS set shows a stronger algorithm is in 
use in addition to a weak one, the validator can make a note of that 
(exclude the weak algorithm from what's acceptable).  I.e., it's not 
possible to "sneak one by" the validator by stripping signatures.

Stepping down into the zone, if the zone in question is the answer's 
owner (or has a further zone cut, the same will apply to the 
subsequent DS set), then we can look back at the answer.  What 
signatures are there?  Is it evident that a "necessary one" is 
missing?  The answer is yes, because the validator knows from the DS 
what to expect and the validator knows what it has on hand.

There's no downgrade attack that will get past this point if the 
validator has it's local policy implemented.

It's like saying someone's hall pass is good if it is signed by the 
principal but if the principal didn't object then a teacher can okay 
it.  (A teacher can't veto the principal.)  If the principal checked 
it and denied it yet the teacher signed it, the hall monitor can tell 
- if it is evident that the principal checked it.  If the result of 
the check isn't available, policy should prevent access, regardless 
of the lower level approval, right?

Turning this around - what if the hall monitor saw that the principal 
had approved but there was no word from the teacher?  It's a waste of 
time for the teacher's approval to be sought, because policy says the 
principal rules.  Even if the teacher is supposed to have an approval 
there, the lack if it isn't important.  Holding up the student will 
just irritate the student at that point.

DNSSEC is to protect the cache and it is up to validators to apply 
the necessary policy to meet the goals of DNS and security.  Get the 
answer fast and reliable.  DNSSEC is not about letting zone admins 
dictate to consumers how the zone is secured.  Zone admins are adding 
ancillary data to allow validators to make their checks.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Edward Lewis <[email-masked]>
Date: Fri, 1 Apr 2011 10:57:40 -0400

>necessarily eack key) present in the zone's DS RRset or configured

Looking at my previous message, this probably makes sense.

Just like NS sets - if the cut point NS set is a subset of the 
corresponding apex NS set things work out, if the algorithms in the 
DS set are a subset of the algorithms in the corresponding DNSKEY 
set, things work out.  And the flexibility to allow a change to be 
made on one side happen non-atomically with a change on the other 
side can proceed.

This works for adding and subtracting.

If I add an NS to the child and then the parent, no lame servers.  If 
I subtract the NS from the parent and then from the child, no lame 
servers.  I make the change in a different order between adds and 
deletes, but the same result, the upper is a subset of the lower.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Mark Andrews <[email-masked]>
Date: Sat, 02 Apr 2011 16:57:10 +1100

I don't thing one should be checking the presence of all algorithms
in the DS RRset for accepting the answer as valid however there is
some benefit in checking that all algorithms in the DS RRset are
present for cache acceptance when there is a down stream validator
which may have a different set of algorithms it supports.

One may want to tag a answer without all the algorithms in the DS
RRset and not return it to DO=1 queries.  Such a answer is perfectly
fine for DO=0 queries and non EDNS queries.

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

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 2 Apr 2011 08:37:22 +0200

On Apr 1, 2011, at 4:24 PM, Samuel Weiler wrote:

> This is a proposed change in DNSSECbis that arguably changes the mandatory algorithm rules.  I'm posting this as a summary of what I understand some may support, I don't support this change myself. Please post in this thread with your support or lack thereof.
> 
> 
> In order to provide some protection against algorithm downgrade[1], we're defining a mechanism for zone signers to signal to validators that a SET of algorithms should ALL be checked, when possible, before determining that an answer from the zone is Secure.  Specifically, we're overloading the DS RRset to do that signalling.
> 
> Validators SHOULD check signatures from all algorithms present in a zone's DS RRset or trust anchors before declaring an answer from the zone to be Secure.  If it is impossible to validate an answer with one or more of those algorithms, the answer SHOULD be treated as Bogus.
> 
> This is a subset of the checks unbound was performing that let to the discovery of the problems with .cz's algorithm roll process.
> 

I do not support this change. It makes DNSSEC validation both more mushy and more brittle by having zones "signal" to relying parties what the zone wants the relying parties to do. It is more mushy because a clearer statement can be made: just sign with the algorithms you want. It makes it more brittle because now there are more ways to make a zone accidentally go bogus.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 2 Apr 2011 08:39:43 +0200

> necessarily eack key) present in the zone's DS RRset or configured

I oppose this because it makes DNSSEC more brittle for no good cryptographic reason. If a zone no longer trusts a signature algorithm, they can stop using it.

--Paul Hoffman

---

From: Brian Dickson <[email-masked]>
Date: Sat, 2 Apr 2011 14:42:49 -0400

I think there is one specific place, where (a) there is value in stricter
checking, where (b) the cost of doing so is reasonably low, and where (c)
that however low the risk may be, the risk-cost-value equation (low risk,
low cost, high value) favors the SHOULD level of "check all known
algorithms, and check for the presence of signatures which match algorithms,
in the DS RRSET.

That place is, signatures on both the apex DNSKEY RRSET and the
corresponding DS RRSET. (I.e., the SEP to the KSK).

However unlikely it is that an RRSIG for a RRSET could be forged, the
consequences of such a forged signature for a substituted "stripped down"
DNSKEY RRSET and/or DS RRSET (which, instead of a robust set of DNSKEY
algorithms, contains just one algorithm, for which the key has been
compromised or for which a new key has been installed) are significant.

The impact would be that, in that cache, every other algorithm and every
signature on every RRSET in the zone would then be BAD, since the algorithms
would not be found, and the RRSIGs would fail to validate (either for bad
signature, or lack of chain of trust back to the root or any trust anchor).
The resolver would then attempt to retrieve valid answers by querying the
forger's server, for everything in the zone.

The attacker would thus be able ensure the downgrade attack would succeed on
the entire zone, and in all likelihood the downgrade would not generally
risk detection (i.e. that the bulk of operators of validating resolvers
would either not recognize that there is a problem, or not understand what
the problem is). Depending on local policy and implementer's choices, it is
possible that no warnings or errors would even be generated.

Any cached data (i.e. from the "good" authority server, vs the forger) would
be either tossed, or be moved to the BAD cache and have a new (short) TTL
applied, and would not be returned to the client except when CD=0, and would
fail to validate anyway (where FAIL == BOGUS).

On the other hand, whenever there is more than one algorithm, and DS/DNSKEY
checking is stronger than "any algorithm, any signature", the requirements
on an attacker are to either look for a weaker spot (individual
other-RRtypes), dedicate a lot more resources, or just give up. If more than
one algorithm needs to be defeated, the risk of any single algorithm being
*the* problem goes away. The attack window on "regular" RRSIGs in a zone
will tend to be much smaller (due to lower TTLs and re-signing, and easy key
rollover within any given algorithm), and the duration of the results of a
successful attack correspondingly small, which also works against a
potential attacker. This is presuming the ZSKs are rolled reasonably
frequently - an action which invalidates cached RRSIGs signed by the
previous ZSKs, i.e. for any given algorithm.

I can't comment on the likelihood that weaknesses in two or more algorithms
being found and exploited within a given time window, but I suspect it's
rather low.

And having multiple signatures (which multiple algorithms necessarily
implies) all needing to validate, makes possible the separation of
key-holders, avoiding single-point-of-exploitation on the signing side, as
well. Specifically, key separation for the KSK (the real high-value target).

Brian

P.S. I know we're talking about extraordinarily low probabilities to start
with, in terms of being able to "get lucky" in doing a brute force attack.
However, there is benefit in terms of the social engineering side, if key
separation for even low-value keys becomes commonplace. In both cases, there
is benefit at reasonably low costs to both authority  operators and
validator operators. SEPs are everything in DNSSEC, and thus, SEPs need
pretty strong protection.

On Sat, Apr 2, 2011 at 2:37 AM, Paul Hoffman <[email-masked]> wrote:

> understand some may support, I don't support this change myself. Please post
> in this thread with your support or lack thereof.
> >
> >
> > In order to provide some protection against algorithm downgrade[1], we're
> defining a mechanism for zone signers to signal to validators that a SET of
> algorithms should ALL be checked, when possible, before determining that an
> answer from the zone is Secure.  Specifically, we're overloading the DS
> RRset to do that signalling.
> >
> zone's DS RRset or trust anchors before declaring an answer from the zone to
> be Secure.  If it is impossible to validate an answer with one or more of
> those algorithms, the answer SHOULD be treated as Bogus.
> >
> I do not support this change. It makes DNSSEC validation both more mushy
> and more brittle by having zones "signal" to relying parties what the zone
> wants the relying parties to do. It is more mushy because a clearer
> statement can be made: just sign with the algorithms you want. It makes it
> more brittle because now there are more ways to make a zone accidentally go
> bogus.
>
> --Paul Hoffman
>

---

From: "Marc Lampo" <[email-masked]>
Date: Mon, 18 Apr 2011 09:39:23 +0200 (CEST)

(sorry for the late reply - catching up ...)

I am not in favour of publishing DS records (in the parent)
referring towards DNSKEY records that are not present (in the child zone).
 (is this change seems to propose)

Motivation :
As registry we try to protect the chain-of trust towards our customers
by validating DNSSEC information presented to us.
Up till now, we have had several cases where such "orphaned" DS records
actually turned out to be configuration errors.
As our validation warned about this, we did not contribute to a broken
chain-of-trust.

If orphaned DS records were to become common,
we can no longer easily distinguish between "normal" and "error"
situation.

Kind regards,

Marc Lampo

-----Original Message-----
From: Samuel Weiler [mailto:[email-masked]] 
Sent: 01 April 2011 04:28 PM
To: [email-masked]
Subject: [dnsext] MAR proposal #2: Allowing pre-publishing of DNSKEYs

My opinion:

-- Sam

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 18 Apr 2011 10:36:13 +0200

Hi Marc,

>  (is this change seems to propose)

This is a different proposal.

> we can no longer easily distinguish between "normal" and "error"

You should check if there is at least one DS record that refers to an
existing DNSKEY (per algorithm). Two DS records of which one is pointing
to a DNSKEY record that does exist and one that doesn't is a valid and
thus "normal" situation.

Best regards,

Matthijs

---

From: Joe Abley <[email-masked]>
Date: Mon, 18 Apr 2011 10:24:18 -0400

On 2011-04-18, at 04:36, Matthijs Mekking wrote:

> Two DS records of which one is pointing

It's also commonly observed during a KSK roll in a child zone, especially for TLDs where the process for submitting new DS RRs to the root zone (or removing old ones) is not instantaneous.

Joe