Subject: [dnsext] Clarifying the mandatory algorithm rules

From: Samuel Weiler <[email-masked]>
Date: Thu, 18 Nov 2010 06:02:05 -0500 (EST)

Recently CZNIC reported on some algorithm rollover problems they 
encountered when they didn't follow the "mandatory algorithm rules" in 
the "Zone Signing" section of RFC4035.  These rules create a method to 
signal to resolvers what algorithms are in use in a zone.  As 
historical perspective, these rules were written in order to avoid the 
dilemma of opening resolvers to a downgrade attack or discouraging the 
use of new algorithms.

CZNIC published a DNSKEY for a "new" algorithm without simultaneously 
publishing the corresponding RRSIGs.  Unbound started rejecting 
answers from .cz because the zone didn't also include the new RRSIGs, 
even though Unbound fully supported the old algorithm and the RRSIGs 
for that old algorithm were present in the zone.

These rules are indeed for zone operators and/or signers and do not 
need to be enforced by a validator.  While I haven't worked through 
the validation sections of 4035 closely, I think Unbound is violating 
the RFC by checking for this.  (It would fine for Unbound to disable 
support for the "old" algorithm entirely, in which case the answers 
should indeed be rejected, but that isn't what happened here.)  In 
contrast, BIND found the signatures from the "old" algorithm 
sufficient.

I've heard folks from CZNIC advocating adding some clarifications to
4641bis and other operational documents reminding zone operators of
these rules, perhaps in better language.  I generally support that.

I've also been encouraged to add an explanation of this to 
dnssec-bis-updates.  Since validator implementers did different 
things, I agree that clarification is in order.

The most general thing we could say is "Pay attention to the section 
headings in RFC4035.  Note that Section 2 ("Zone Signing") provides 
guidance to zone signers, not resolvers.  Resolvers should pay careful 
attention to Sections 4 and 5 ("Resolving" and "Authenticating DNS 
Responses") and do not need to separately check for compliance with 
every item in Section 2.  In particular the "mandatory algorithm 
rules" in the last paragraph of section 2.2 do not need to be enforced 
by a resolver.  Note that this document makes some minor changes to 
the validation rules in RFC4035, including the rules for handling DS 
records with unknown message digest algorithms."

I'm not sure if the generalization (that validators can ignore section 
2) is 100% correct.  Is it?

Alternatively, we could say something specific:

"The last paragraph of RFC4035 Section 2.2 includes rules for which
algorithms must be used to sign a zone.  Since these rules have been
confusing, we restate them in different language here:

Every algorithm present in a zone's DS RRset (if any) must also be 
present in its DNSKEY RRset.  Every algorithm present in the DNSKEY 
RRset must be used to sign every RRset in the zone, including the 
DNSKEY RRset itself.  If more than one key of the same algorithm is in 
the DNSKEY RRset, it is sufficient to sign each RRset with any subset 
of these DNSKEYs.  It is acceptable to sign some RRsets with one 
subset of keys (or key) and other RRsets with a different subset, so 
long as at least one DNSKEY of each ALGORITHM is used to sign each 
RRset.  Likewise, if there are DS records for multiple keys of the 
same algorithm, any subset of those may appear in the DNSKEY RRset.

Furthermore, note that these rules are for zone operators and zone
operators, as might be inferred from the Section 2 heading: "Zone
Signing".  These rules do not need to be separately enforced by
validating resolvers."

Does the WG have a preference for which version of this to add to 
dnssec-bis-updates?  By default, I propose to add the specific one. 
If someone else has walked through RFC4035 Sections 4 and 5 carefully, 
perhaps we could use the general one.  I also welcome other 
restatements of the rules: I wrote the original ones which have been 
confusing, and having someone else rewrite them might make more sense.

-- Sam Weiler

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 18 Nov 2010 12:20:33 +0100

Hi Sam,

I actually gave it some thought yesterday and there is one thing I still 
don't understand.  If the case is indeed to protect against downgrade 
attack then if the resolver doesn't implement same strictness as zone 
operators then there is in fact no protection at all against downgrade 
attack.

Maybe it's a right time to clarify what the downgrade attack is.  My 
understanding is that:

1) there is a known cryptographic attack against algorithm A

2) there is a algorithm B which is safe to use

3) the zone operator publish zone with algorithm A and B in the apex

4) the zone is signed by both algorithm A and B (Note: when I say signed 
by algorithm I mean signed by key or chain of keys (KSK+ZSK) using that 
particular algorithm)

5) an attacker computes the signature for his spoofed records using 
algoritm A

6) an attacker injects his spoofed RRs together with computed sigs to a 
validating resolver

7) if the validating resolver is OK with just one or another and not 
both algorithm signatures, it could be convinced to validate the result 
just by seeing (spoofed) signatures with algorithm A.  So the validating 
resolver sees spoofed records and it's spoofed signatures using just 
algoritm A and it validates the result.

What do I miss here?  I really do think that there is no downgrade 
attack protection if it's not implemented on both sides (authoritative 
and validating-recursive).

Ondrej.

On 18.11.2010 12:02, Samuel Weiler wrote:
> signal to resolvers what algorithms are in use in a zone. As historical
> perspective, these rules were written in order to avoid the dilemma of
> opening resolvers to a downgrade attack or discouraging the use of new
> algorithms.
>
> publishing the corresponding RRSIGs. Unbound started rejecting answers
> from .cz because the zone didn't also include the new RRSIGs, even
> though Unbound fully supported the old algorithm and the RRSIGs for that
> old algorithm were present in the zone.
>
> These rules are indeed for zone operators and/or signers and do not need
> to be enforced by a validator. While I haven't worked through the
> validation sections of 4035 closely, I think Unbound is violating the
> RFC by checking for this. (It would fine for Unbound to disable support
> for the "old" algorithm entirely, in which case the answers should
> indeed be rejected, but that isn't what happened here.) In contrast,
> BIND found the signatures from the "old" algorithm sufficient.
>
>
> dnssec-bis-updates. Since validator implementers did different things, I
> agree that clarification is in order.
>
> every item in Section 2. In particular the "mandatory algorithm rules"
> in the last paragraph of section 2.2 do not need to be enforced by a
> resolver. Note that this document makes some minor changes to the
> validation rules in RFC4035, including the rules for handling DS records
> with unknown message digest algorithms."
>
> present in its DNSKEY RRset. Every algorithm present in the DNSKEY RRset
> must be used to sign every RRset in the zone, including the DNSKEY RRset
> itself. If more than one key of the same algorithm is in the DNSKEY
> RRset, it is sufficient to sign each RRset with any subset of these
> DNSKEYs. It is acceptable to sign some RRsets with one subset of keys
> (or key) and other RRsets with a different subset, so long as at least
> one DNSKEY of each ALGORITHM is used to sign each RRset. Likewise, if
> there are DS records for multiple keys of the same algorithm, any subset
> of those may appear in the DNSKEY RRset.
>
> dnssec-bis-updates? By default, I propose to add the specific one. If
> someone else has walked through RFC4035 Sections 4 and 5 carefully,
> perhaps we could use the general one. I also welcome other restatements
> of the rules: I wrote the original ones which have been confusing, and
> having someone else rewrite them might make more sense.
>
> -- Sam Weiler
>
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

-- 
  Ondřej Surý
  vedoucí výzkumu/Head of R&D department
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 18 Nov 2010 12:32:20 +0100

Based on off-list discussion with Sam, I should add that both algorithm 
A and algorithm B in my example are supported by the validating resolver.

Ondrej

On 18.11.2010 12:20, Ondřej Surý wrote:
> What do I miss here? I really do think that there is no downgrade attack
> protection if it's not implemented on both sides (authoritative and
> validating-recursive).
>
> Ondrej.
>

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 18 Nov 2010 06:37:49 -0500 (EST)

> 1) there is a known cryptographic attack against algorithm A
...
> algoritm A and it validates the result.

This is a different sort of downgrade attack than the one these rules 
were designed to protect against.  Indeed, to address this attack 
within the protocol, we'd need to require resolvers to check EVERY 
algorithm's signature (if they can).  We didn't do that before, and 
it's probably unwise to make that change now.

The current work-around is for the zone owner to STOP signing with the 
known-broken algorithm A.  That leaves code that only supports A out 
in the cold.  If you're assuming resolvers support both A and B 
(as your clarification says), there's no problem.

> and validating-recursive).

Indeed, for the attack you're describing, the resolver would need to 
be involved, and it would need to change.

The downgrade attack that led to this is documented in a message to 
namedroppers on 13 August 2003, Subject line "DNSSECbis Q-2: 
degradation attack".  With the archives off-line, perhaps I should 
resend it.

-- Sam

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 18 Nov 2010 12:48:35 +0100

Hi Samuel,

Several people have complained that unbound is too strict, and I keep
defending this.  I do claim to be RFC conformant; and I want to oppose
the change.  (but not the clarification of signing rules).

> opening resolvers to a downgrade attack or discouraging the use of new

This is what I do, I want to avoid a downgrade attack.  A proper signed
zone has these signatures.  They are missing.  Something is wrong.

> old algorithm were present in the zone.

Yes.  Even though one signature worked, because the other did not work
(was 'stripped off') it was obvious that there was a downgrade attack.
Signatures had been removed from the answer.  To be safe, unbound blocks
this suspect content.

And if you interpret the downgrade to include algorithm-downgrade, then
it might be unbound itself that is under a downgrade attack.  It is
certain that someone-else (that has less algorithm support) is getting a
signature-presence-downgrade attack.

> to be enforced by a validator.  While I haven't worked through the

I am ok with OPTIONAL.  I understand cryptographically it works with a
single signature, but operationally I do not agree with you.
Operationally, something really bad is happening.

> BIND found the signatures from the "old" algorithm sufficient.

You must not be lenient with security.

I disagree, I am not violating the RFC.  I choose to reject zones that
are not signed properly.  You understand that unbound gets
algorithm-downgrade-protection from applying this policy?  There is
actual security benefit to this policy?

> these rules, perhaps in better language.  I generally support that.

Yes, people should know how to keep it signed properly.

> dnssec-bis-updates.  Since validator implementers did different things,
> I agree that clarification is in order.
> 

No, don't do this, it makes the situation less understandable; I want to
reject this because referring to section headers is perhaps something of
an excuse, but not good for understanding.

> confusing, we restate them in different language here:

Perhaps the above paragraph can be shortened, 'rules are restated here'.

> RRset must be used to sign every RRset in the zone, including the DNSKEY
> RRset itself.  If more than one key of the same algorithm is in the
> DNSKEY RRset, it is sufficient to sign each RRset with any subset of
> these DNSKEYs.  It is acceptable to sign some RRsets with one subset of
> keys (or key) and other RRsets with a different subset, so long as at
> least one DNSKEY of each ALGORITHM is used to sign each RRset. 
> Likewise, if there are DS records for multiple keys of the same
> algorithm, any subset of those may appear in the DNSKEY RRset.

I agree with this text, and I like it.

I would like you to add that 'extra signatures are allowed to be present
(that have nothing to do with the keys in the DNSKEY rrset)'.  I want to
add it because people asked me that as a question.

It states something new: the DNSKEY RRset must be signed with every
algorithm present in the DNSKEY RRset validly.  This makes a (small)
difference to the revoke step in the
RFC5011-singlecombinedkey-algorithm-rollover scheme, where the DNSKEY
must also be signed with the temporary-ZSK (I believe).  Some signers
take leeway when no DS points to a zone, since the DNSKEY does not get
validated with those algorithms by current validator implementations.
But I am OK with this change.

> Signing".  These rules do not need to be separately enforced by

I do not agree with this, because it diminishes security.

> having someone else rewrite them might make more sense.

You are removing algorithm-downgrade protection, even though the current
rules seem to make this optional today.  I disagree with that.

If someone decides to sign his zone (permanently, not rollover) with
algorithms X and Y, he should get protection from X AND Y, not X OR Y
when this is possible and implemented.  The protocol can easily deal
with this, we should not allow misconfiguration.

Best regards,
   Wouter

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 18 Nov 2010 13:02:53 +0100

Hi Sam,

You seem to want to enforce an original idea (which Mark understood
perfectly, it seems), about protection from signature-missing.  This is
not what RFC4035 says.

On 11/18/2010 12:37 PM, Samuel Weiler wrote:
> were designed to protect against.  Indeed, to address this attack within
> the protocol, we'd need to require resolvers to check EVERY algorithm's
> signature (if they can).  We didn't do that before, and it's probably
> unwise to make that change now.

That is what unbound does.  And it gets algorithm downgrade protection
security as a benefit (for the algorithms that it implements).

Since owners MUST sign their zone correctly, I see no need to specify a
MUST accept missing signatures if you implement the other algorithm?
Why do you want to allow inproperly-signed zones?  It will break
resolvers that implement only a subset of algorithms?

> Indeed, for the attack you're describing, the resolver would need to be
> involved, and it would need to change.

Unbound would not need to change.  Today, if people sign their zones
properly, this is compatible with BIND and Unbound.

Because it is unknown if future algorithm numbers may allow signatures
to be absent; unbound does not check if signatures are missing for
algorithms that it does not implement (and anyway a spoofed signature
would trivially get accepted since it cannot validate).

> namedroppers on 13 August 2003, Subject line "DNSSECbis Q-2: degradation
> attack".  With the archives off-line, perhaps I should resend it.

No.

Best regards,
   Wouter

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 18 Nov 2010 08:46:04 -0500

I can't quite understand why we would make a change to require acceptance of
the unsigned zone in this case.

1) What is easier, for operators to change their behavior and sign before
they publish keys or for resolvers to change their behavior.

2) What is more secure, to protect against the downgrade attack or to allow
it for the sake of incompetent signers?

3) What is more sustainable? If the WG accepts this change, what is the
probability others will implement a choice that appears eccentric and wrong?

Absent a really compelling reason to allow for zones to be signed in this
way, I can't see why we would not change the operations section rather than
the validation. Is there any reason that the operators cannot publish the
signatures before the keys?

The problem of what relying applications should to do when a zone is
incorrectly signed is much more general than this one example and one that I
don't think has been fully considered by those advocating end-to-end DNSSEC
design with the validation taking place at the relying application.

This is a general problem in cryptographic protocols: if there is no
possibility of an attack succeeding, there is no point in attempting the
attack. Therefore the probability that a signature is failing because of an
attack falls to zero and the overwhelming likelihood is that the cause of
any failure is misconfiguration.

There are controls that can be implemented to mitigate this but they depend
on having more state information than an endpoint can acquire on its own.

On Thu, Nov 18, 2010 at 7:02 AM, W.C.A. Wijngaards <[email-masked]>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Sam,
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkzlFe0ACgkQkDLqNwOhpPjODACcCjh2uSefIUiMUdTtpJit9yfa
> 5fEAn2aYmizlQcZm4sJVQgjfFv/FJSEj
> =I/FY
> -----END PGP SIGNATURE-----

-- 
Website: http://hallambaker.com/

---

From: Florian Weimer <[email-masked]>
Date: Thu, 18 Nov 2010 14:05:42 +0000

> security as a benefit (for the algorithms that it implements).

And I don't see any other way to get a priori downgrade protection.
There is no ordering of algorithm strengths.  For example, we don't
know if SHA-1 or SHA-256 will be broken first.

A posterio, you can drop validation for known-to-be-broken algorithms.
But even that might be not so easy because it's somewhat subjective
when an algorithm is broken.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Jelte Jansen <[email-masked]>
Date: Thu, 18 Nov 2010 15:33:11 +0100

> to be enforced by a validator.  While I haven't worked through the

So what you're saying is that validators should not check for something
because the signer (or the operator) might not be following the spec and
that may break stuff?

Or, more generally, why say that you MUST do a, then say that you
SHOULD/MAY NOT check whether A was done?

IMHO, we should either do downgrade protection for all cases (which is
how i interpret the rfc too, and yes i am aware that this makes
algorithm rolls a PITA, but see below), and not just a specific subset,
or leave it out completely.

btw. the 'loose' interpretation would still make the hypothetical case
fail where the *old* algorithm is not supported by a validator, but the
new one is. And if algorithms are going to be obsoleted, perhaps that
case will not be that hypothetical in the future. But perhaps that is
exactly why that text is there (and why, whether or not validators check
for it, the procedure that triggered this round of discussion was still
wrong).

Jelte

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 18 Nov 2010 10:06:04 -0500 (EST)

On Thu, 18 Nov 2010, Phillip Hallam-Baker wrote:

> I can't quite understand why we would make a change to require 
> acceptance of the unsigned zone in this case.

There is a difference of opinion about what's being "changed" here. 
I think my proposed clarification is NOT a change -- RFC4035 does not 
tell resolvers to do what Unbound is doing.  Wouter seems to disagree.

>From my perspective, it's Wouter (and you?) that wants to make a 
change, in the form of requiring resolvers to check something RFC4035 
doesn't require them to check.

Different perspectives.

The "check everything and fail if anything break" seems to differ in 
spirit from the guidance that's already in dnssec-bis-updates; see 
section 5.4 "Caution About Local Policy and Multiple RRSIGs". 
(Slightly different details, same flavor.)  That section has been in 
this doc since the -00 version, dated May 2005.

While there may be merit in the approach Wouter suggests, my 
inclination as doc editor is to avoid changes unless strictly 
necessary.

Since we seem to have different ideas about the current state of the 
world, perhaps we need some more voices in this.  Perhaps the BIND 
authors have an opinion.  :-)

-- Sam

---

From: Brian Dickson <[email-masked]>
Date: Thu, 18 Nov 2010 11:10:50 -0400

On Thu, Nov 18, 2010 at 7:02 AM, Samuel Weiler <[email-masked]> wrote:
> Recently CZNIC reported on some algorithm rollover problems they encountered
> when they didn't follow the "mandatory algorithm rules" in the "Zone
> Signing" section of RFC4035.  These rules create a method to signal to
> resolvers what algorithms are in use in a zone.  As historical perspective,
> these rules were written in order to avoid the dilemma of opening resolvers
> to a downgrade attack or discouraging the use of new algorithms.
>
> publishing the corresponding RRSIGs.  Unbound started rejecting answers from
> .cz because the zone didn't also include the new RRSIGs, even though Unbound
> fully supported the old algorithm and the RRSIGs for that old algorithm were
> present in the zone.
>
> These rules are indeed for zone operators and/or signers and do not need to
> be enforced by a validator.  While I haven't worked through the validation
> sections of 4035 closely, I think Unbound is violating the RFC by checking
> for this.  (It would fine for Unbound to disable support for the "old"
> algorithm entirely, in which case the answers should indeed be rejected, but
> that isn't what happened here.)  In contrast, BIND found the signatures from
> the "old" algorithm sufficient.
>
>

What server software were they running?

The whole point of "MUST" is that compliant implementations do exactly
the "MUST" thing.

The zone operator should be aware of the rules, but the authority
server software really
should be enforcing the rules. If it doesn't, it's at least a bug, if
not an RFC violation.

The zone should not have been able to be loaded with the signatures missing.

And given that it did, I'd say unbound did everyone a favor in this
instance, highlighting both
the operational issue, and the RFC issue we're discussing here.

Brian

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 18 Nov 2010 10:17:21 -0500 (EST)

On Thu, 18 Nov 2010, W.C.A. Wijngaards wrote:

> Since owners MUST sign their zone correctly, I see no need to 
> specify a MUST accept missing signatures if you implement the other 
> algorithm? Why do you want to allow inproperly-signed zones?  It 
> will break resolvers that implement only a subset of algorithms?

Honestly, I haven't thought about the constraint in this light.

Some hisorical perspective may help.

Before these mandatory algorithm rules were adopted, a "properly 
signed" zone required that each RRset be signed by ANY of the DNSKEYs 
in the zone, with no regard to algorithms.  Some RRsets could be 
signed only with alg 5, some only with alg 234, and some with both.

We adopted these mandatory algorithm rules to deal with a particular 
downgrade attack (or, depending on how you look at it, a debilitating 
incentive against deploying a new algorithm).  For this purpose, it 
was (and is) sufficient to require a zone to follow the rules.  It was 
(and is) not necessary to require the resolver to check that the zone 
had followed the rules.

So we're starting from different places: I still remember the 
arguments from 2003 about why we should have ANY restrictions.  I also 
remember talking about whether we wanted to address other downgrade 
possibilities (e.g. key length) -- the WG decided not to tackle any of 
that.

-- Sam

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 18 Nov 2010 10:19:34 -0500 (EST)

> The zone should not have been able to be loaded with the signatures 

Concur.

> instance, highlighting both the operational issue, and the RFC issue 
> we're discussing here.

Concur re: operational issue.  I don't think there is an RFC issue 
(other than clarity, obviously).

-- Sam

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 18 Nov 2010 21:16:12 +0100

Sam,

we discussed it with Jaromir on our walk to Vatican Museum and came to 
conclusion that validating resolver only needs to stop and declare 
security problem only when there is a chain of trust leading to a key 
with a new algorithm and there are missing signatures for that algorithm.

So the resolver should return SERVFAIL only when (all conditions must 
apply):

a) there are DS records in parent zone for algorithm A and algorithm B

b) the zone has keys for algorithm A and algorithm B in the zone apex 
(it has to according to RFC)

c) there are signatures either only for algorithm A or only for algorithm B

The idea is that just adding a new key with algorithm B (the strong) 
without chaining it to the parent zone doesn't add any new security, 
since the chain of trust is secured by the (the weak) algorithm A.

So, yes the RFCs need a clarification and yes the unbound is 
unnecessarily strict since such strict implementation doesn't add any 
additional security (because you don't have a chain of trust leading to 
a key).  Wouter, object now or never :).

Sam, thanks for your persistence :), the "unsupported algorithm" was the 
missing piece I was looking for.

Ondrej

On 18.11.2010 12:37, Samuel Weiler wrote:
>> both algorithm signatures, it could be convinced to validate the
>> result just by seeing (spoofed) signatures with algorithm A. So the
>> validating resolver sees spoofed records and it's spoofed signatures
>> using just algoritm A and it validates the result.
>
> known-broken algorithm A. That leaves code that only supports A out in
> the cold. If you're assuming resolvers support both A and B (as your
> clarification says), there's no problem.
>

Please do.

Ondrej

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 18 Nov 2010 21:20:54 +0100

> know if SHA-1 or SHA-256 will be broken first.

(See my other mail.)  You don't get a downgrade protection before 
chaining the new algorithm to the parent zone.

> when an algorithm is broken.

Dropping the know-to-be-broken algorithms doesn't help the old 
non-upgraded resolvers, hence we should not rely on anything like that.

Ondrej

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 18 Nov 2010 21:37:36 +0100

Wouter, Jelte,

On 18.11.2010 15:33, Jelte Jansen wrote:
> IMHO, we should either do downgrade protection for all cases

I suggest we properly define what a "downgrade protection" is and how 
does it protect the zone.  I've fallen for this trap too and it helped 
me a lot to write it down.

Let's define (I skip KSK and ZSK for sake of sanity and I skip RFC5011 
for the same reason):

Algorithm A is supported.
Algorithm B is also supported.

Zone X has following properties:
   1) DS record for algorithm A
   2) DNSKEY in apex for algorithm A - DNSKEY(A)
   3) Signatures with DNSKEY(A)

Zone Y has following properties:
   1) DS record for algorithm A
   2) DNSKEY in apex for algorithm A - DNSKEY(A)
   3) DNSKEY in apex for algorithm B - DNSKEY(B)
   4) Signatures with DNSKEY(A) and DNSKEY(B)

What you are saying is that Zone Y is more secure than Zone X.  And I 
don't think so, because there is a step when you rely only on algorithm A.

Now let's add:

Zone Z has following properties
   1) DS record for algorithm A
   2) DS record for algorithm B
   3) DNSKEY in apex for algorithm A - DNSKEY(A)
   4) DNSKEY in apex for algorithm B - DNSKEY(B)
   5) Signatures with DNSKEY(A) and DNSKEY(B)

I think that only Zone Z is more secure than Zone X and Zone Y.  And 
because you don't have to keep both DS records for algorithm A and 
algorithm B in the parent zone (ie. you can just exchange the DS) then 
the key algorithm rollover can be less painful.

I would even suggest that the condition of "having the chain of trust" 
from TA to the key with a specific algorithm also applies for Sam's case 
for introducing the new "unknown" algorithm.  But I haven't given it 
much thought and I rather thing it through more before coming to any 
conclusion.

Ondrej

---

From: Brian Dickson <[email-masked]>
Date: Thu, 18 Nov 2010 17:02:04 -0400

I don't think the example is complete or accurate enough, since the
security at the delegation step depends on the parent's algorithms,
not the child's.

See below in-line for additional comments...

On Thu, Nov 18, 2010 at 4:37 PM, Ondřej Surý <[email-masked]> wrote:
> I suggest we properly define what a "downgrade protection" is and how does
> it protect the zone.  I've fallen for this trap too and it helped me a lot
> to write it down.
>
> Let's define (I skip KSK and ZSK for sake of sanity and I skip RFC5011 for
> the same reason):
>
1a) Signatures for DS(A), using DNSKEY(PA),DNSKEY(PB) (parent alg A
and parent alg B) -- may not be the same as A and B
>  1) DS record for algorithm A
1a) Signatures for DS(A), using DNSKEY(PA),DNSKEY(PB) (id.)
> What you are saying is that Zone Y is more secure than Zone X.  And I don't
> think so, because there is a step when you rely only on algorithm A.

NB - the DS does not use the algorithms, it uses (orthogonal to
algorithms) hashes.
If the hash used is more secure than A, then Y is more secure than X.

>  5) Signatures with DNSKEY(A) and DNSKEY(B)

Here is where the example definitely helps in at least presenting the
components for comparison.

If something is seen on the wire in zone Z, without the signature
DNSKEY(B), it might be the result of a downgrade.
I.e., if A is weak, and the signature based on DNSKEY(A) can be
spoofed, this needs to be protected against.
This also means the signatures over the DNSKEYs at the apex similarly
need downgrade protection, and can only be used/trusted,
if they all match those found in the corresponding DS set of the parent.

If the parent DS is not the source of the list of algorithms which
must all be used for signing everything in the zone, downgrades are
possible.

I think there is wiggle room for the addition of new DNSKEYs and
algorithms, via the ZSK/KSK linkage, that differs slightly.

I.e. KSK must match DS for algorithms, and ZSK must match RRSIG for
algorithms. It is possible that algorithms present in ZSKs are not
present in KSKs.
And in such a case, unbound is correct and bind is incorrect, IMHO.

Brian

> I think that only Zone Z is more secure than Zone X and Zone Y.  And because
> you don't have to keep both DS records for algorithm A and algorithm B in
> the parent zone (ie. you can just exchange the DS) then the key algorithm
> rollover can be less painful.
>
> I would even suggest that the condition of "having the chain of trust" from
> TA to the key with a specific algorithm also applies for Sam's case for
> introducing the new "unknown" algorithm.  But I haven't given it much
> thought and I rather thing it through more before coming to any conclusion.
>
> Ondrej
> --
>  Ondřej Surý

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 18 Nov 2010 22:31:41 +0100

> algorithms, via the ZSK/KSK linkage, that differs slightly.

Indeed.  But I see that as a variation of "must have a chain of trust" 
and relation between DS(parent)-DNSKEY(child).

> algorithms. It is possible that algorithms present in ZSKs are not

Although bind doesn't treat this case as a valid zone and 
dnssec-signzone has to be silenced with -P, I was unable to find the 
reference to invalidity of such zone neither in 403[3-5] nor 3757.  That 
doesn't mean it doesn't exists, just that I didn't find it.

> And in such a case, unbound is correct and bind is incorrect, IMHO.

My feeling is that the same rule about DS-DNSKEY should apply for 
KSK-ZSK.  So if you publish a ZSK(A) and ZSK(B) and sign them with your 
KSK, you have to have RRSIG(ZSK(A)) and RRSIG(ZSK(B)) over all RRs in 
your zone.

O.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 19 Nov 2010 11:41:34 +1100

The intent of this section was to prevent downgrade to insecure due
to a attacker dropping RRSIGS.  DNSSEC has always been "if *any*
signature validates then the RRset validates".  There is no concept
of a "more secure algorithm" in DNSSEC.  There may be outside of
DNSSEC but not inside.

If the archives were online you could see that this was the intent
of this paragraph.

When a operator of a zone publishes DS (or trust-anchors) for a
zone with a algorithm that is a claim that the entire zone is signed
with that algorithm.  That claim will continue to hold for the life
of the DS records or until the operator can be assured that the
trust anchors have been removed for the algorithm, whichever is
longer.

Additionally the MUST is a directive to *zone operators*.  A zone
operator can comply with that MUST but validation will still fail
with unbound as unbound requires that a zone be signed with DNSKEYs
which are NOT in the zone prior to adding the DNSKEY to the zone
due to caching.  On this alone it is clear that unbound is in the
wrong.

If you want to do downgrade protection between algorithms one can
but only for the algorithms listed in the DS / trust-anchors.  They
are the only algorithms that the zone operator has made any claims
of existance for.

I think the paragraph in question should be relaxed to make to MUST
only apply to algorithms listed in the DS / published trust anchors.
This will allow for gradual introduction of RRSIG for new algorithms.
The current wording prevents this and is a real pain for large
zones.

It will also resolve this issue as now it is the sum of the algorithms
listed in DS (trust-anchors) + DNSKEY.

Mark

P.S. we need a better way to publish trust anchors in-band with
lifetimes etc. so that one can be assured that trust anchors expire
like DS and zones expire but that should be a different discussion.
RFC 5011 really isn't good enough.

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

---

From: Brian Dickson <[email-masked]>
Date: Fri, 19 Nov 2010 01:02:02 -0400

> of a "more secure algorithm" in DNSSEC.  There may be outside of

This is likely what the original intent was, and certainly within the context
of a single algorithm, or a validator that only understands one of the
algorithms
present, then it makes sense that only one RRSIG needs to validate.

However, consider the case of multiple algorithms used (to sign), and
validators that understand just one of those, vs validators that understand
more than one, ideally all of them.

What are the implications of "any RRSIG will do" versus the alternative of
 "one RRSIG of each understood algorithm must validate"?

For brevity, the algorithms are A, B, C, .... and the possible requirements
are either "A | B | C..." (or any subset thereof), or "A & B & C ..."
(or any subset thereof).

It might not be known apriori which of A, B, C, ... is "weaker", or
which might be broken first.

The argument should be, if the "&" logic is used, it doesn't matter.
And in fact, the bad
things that result from "|" result regardless of which is broken first.

If any given algorithm is broken, and only one RRSIG needs to match
(the "|" case),
then every zone signed with that algorithm can subsequently be compromised.
RRSIGs can be produced by an attacker, matching forged data. This
applies not only
to zone data, but also to DNSKEYs, and DS records and their RRSIGs.

The implication as far as both detection, and response, are
substantial. Removal of the bad
algorithm would be mandated, and need to happen extremely fast, on the
data side. Zones would
need to be re-signed completely. The rest is left as an exercise for
the paranoid reader.

On the other hand, if the requirement is that all understood
algorithms present, must have a valid
matching RRSIG, then having even two algorithms (in common between the
signer and validator)
changes everything.

The compromise of one algorithm has no immediate implication, since
forgeries cannot occur without
forging the RRSIGs for all known algorithms. At worst, validators that
only understand one of the
algorithms used, and specifically the broken algorithm, are exposed to
attack. Everyone else can safely
respond at their leisure, with no need for drastic immediate action.

The incremental cost of signing, and of validating, multiple RRSIGs,
is linear, O(n) where n is the number of algorithms.
For zone owners who are already signing using multiple algorithms, the
incremental cost is zero.
And for validating, caching resolvers, the incremental cost occurs
only the first time the record is retrieved, and validated.
Once validated, and cached, there is no incremental cost.

So, my suggestion is, if we need to revisit the scope of the -bis to
incorporate this logic, perhaps we should.
And if it can be already considered in-scope, the benefits arguably
outweigh the concerns of  "changing the meaning" of the  existing
RFC(s).

Brian

> are the only algorithms that the zone operator has made any claims

I'm unclear here. Are you arguing that downgrade protection is signaled
by the zone owner via DS using multiple algorithms, and if signaled is mandatory
for implementations to do?

Or that downgrade protection is optional, and can only be done for algorithms
present in DS/trust anchors?

> The current wording prevents this and is a real pain for large

I like gradual introduction of RRSIGs for new algorithms.

I do not like optional for downgrade protection.

Downgrade protection for algorithms is every bit as important as
downgrade to insecure.
Precisely because a broken algorithm *is* insecure, in fact.

> listed in DS (trust-anchors) + DNSKEY.

I'm fine with excluding DNSKEY, so long as it is the sum of DS/trust-anchors.

Brian

---

From: Mark Andrews <[email-masked]>
Date: Fri, 19 Nov 2010 17:04:15 +1100

In message <AANLkTi=[email-masked]>, Bria
n Dickson writes:
> This is likely what the original intent was, and certainly within the conte=
> xt

It was expressed in the context of multiple algorithms and no one rejected
the premise.
 
> "one RRSIG of each understood algorithm must validate"?

The working group looked at this when making the decision to accept one
signature as good enough.
 
> substantial. Removal of the bad algorithm would be mandated, and need
> to happen extremely fast, on the data side. Zones would

You don't need to remove the broken algorithm from the zone.  You
just need to stop the validator using it to validate.

> algorithms present, must have a valid matching RRSIG, then having even
> two algorithms (in common between the signer and validator)
> changes everything.

This isn't a requirement of DNSSEC and never has been.
 
> forgeries cannot occur without forging the RRSIGs for all known
> algorithms. At worst, validators that only understand one of the
> attack. Everyone else can safely respond at their leisure, with no need
> for drastic immediate action.

Which was understood when the decision to accept any signature was made.

> by the zone owner via DS using multiple algorithms, and if signaled is mand=
> atory
> Or that downgrade protection is optional, and can only be done for algorith=
> ms

If you have multiple algorithms listed in the DS then as a validator
you should expect to be able to validate the response using either
of those algorithms.  If you have a local policy that says "only
trust A if A and B are present" then you can only do that reliably
when the DS lists A and B.  Note this local policy is NOT the default
policy for DNSSEC and would require extensions to a standard validator
to support.

Personally I don't think there is any real benefit in supporting
such a policy.  If you don't trust B just don't use it.

One could also have a local policy of verify all algorithms.  This
too would require extensions to the validator.  You would need to
check all the algorithms in the DNSKEY RRset and record which ones
successfully validated then examine the DS RRset/trust anchors and
check that all the algorithms there were in the successful list
produced from the DNSKEY RRset.  You get algorithm downgrade
protection if you do this.

Note this does not require that you check that there is a signature
for every algorithm in the DNSKEY RRset.

> Precisely because a broken algorithm *is* insecure, in fact.

If a algorithm is insecure then you should remove it from the list
of acceptable algorithms in you validator.  That way you get insecure
not trusted out of the validator.

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 19 Nov 2010 08:02:09 +0100

> The current wording prevents this and is a real pain for large

I agree.  That was exactly what I was trying to say in my last few emails.

Ondrej

---

From: "George Barwood" <[email-masked]>
Date: Fri, 19 Nov 2010 07:06:31 -0000

----- Original Message ----- 
From: "Mark Andrews" <[email-masked]>
To: <[email-masked]>
Sent: Friday, November 19, 2010 12:41 AM
Subject: Re: [dnsext] Clarifying the mandatory algorithm rules

> The current wording prevents this and is a real pain for large

+1

This is how a reasonable person would expect it to work without
consulting the standard, and is the most logical approach.

It reproduces what happens when a zone is first signed, that is
until the DS / trust anchor is published, no verification occurs.

It simplifies removal of an algorithm, by removing the need
to (temporarily) continue to sign RRsets with keys that have
just been removed from the DNSKEY RRset.

The problem I guess is that this is a change to the standard,
and the benefits are not entirely decisive. However if it is
not done I expect zone operators to repeatedly make the same
mistake when changing algorithms.

- George

---

From: Jelte Jansen <[email-masked]>
Date: Fri, 19 Nov 2010 08:40:33 +0100

> not trusted out of the validator.

If you do that, and the zone(s) do 'normal' pre-publish rollover from
that broken algorithm to a not-yet-broken one, you'd get bogus, not
insecure, during the roll

Jelte

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Fri, 19 Nov 2010 10:46:45 +0100

Hi,

> since the chain of trust is secured by the (the weak) algorithm A.

Today, the RFC has rules for DS-DNSKEY and rule for DNSKEY-DATA.  You
want to create new rules for DS-DATA.

> a key).  Wouter, object now or never :).

You called?  Yes, unbound is strict, it enforces the exact zone signing
requirements from the RFC.  But, I am not objecting to you strongly.  I
want to caution making changes to RFC4035, there must be backwards
compatibility.

But the above makes the algorithm-set determined by the parent.
Now, the algorithm set is determined by the child (when you get there).
I appreciate the concern that if you want to protect a downgrade, then
you must signal this at the parent.

(the security of that parent is that of a new zone; with different owners).

> due to caching.  On this alone it is clear that unbound is in the

Let me try to understand this and then respond.  You talk about having
to prepublish signatures before the keys are published.

This is necessary with the current rules today for algorithm-support
reasons.  It does not go away if unbound has less strict checking.  The
affected servers could be bind, unbound or other implementations.

Your change to the rules makes it possible to add the key, and then
signatures slowly, with a new algorithm, (as long as the DS is not added
yet).  I appreciate that niceness.

You are correct that you must also take the trust-anchors into account
to do it properly (and I do not do that today).

Best regards,
   Wouter

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 19 Nov 2010 11:58:42 +0100

> want to create new rules for DS-DATA.

Just to clarify - I agree that what Unbound does is in alignment with 
what RFC says.

> you must signal this at the parent.

Yes.

> to do it properly (and I do not do that today).

I suggest we all think about that and put the result into a -bis document.

Ondrej

---

From: Mark Andrews <[email-masked]>
Date: Sat, 20 Nov 2010 00:16:27 +1100

> insecure, during the roll

No you don't.  Once a algorithm is marked as invalid the validator
behaves exactly as if the validator doesn't know about the algorithm.

During the pre-publish period there isn't a trust path into the zone with
a supported algorithm.
 
Mark

---

From: Mark Andrews <[email-masked]>
Date: Sat, 20 Nov 2010 01:18:52 +1100

> want to create new rules for DS-DATA.

I want to make it possible to do incremental signing of new algorithms
which requires the rules to be relaxed but we can leave discussion of
that until we resolve the issue about whether the validator should be
checking or not.
 
> want to caution making changes to RFC4035, there must be backwards

Except the validator is not supposed to enforce it.  The point of
the rule, for the signer, was to ensure that there would be *a*
signature to validate with.

The downgrade attack it was supposed to protect against is downgrade
to insecure not downgrade between algorithms.

> you must signal this at the parent.

A zone is deem secure or insecure based on the list of algorithms
in the DS RRset.

> affected servers could be bind, unbound or other implementations.

No it isn't necessary.

I start out with algorithm A in DS and DNSKEY.  The DNSKEY has a
TTL of 600.  I have a TXT record with a TTL of 600 which is fetch
300 seconds after the DNSKEY record is fetched.  I add a DNSKEY
with algorithm B and re-sign the entire zone with A+B meeting the
MUST.  301 second later a downstream validating client asks for the
TXT record.  The client get a DNSKEY RRset with A+B and a TXT with
A signatures.  This will validate as secure by a validator that
supports A only.  This will validate as insecure by a validator
that supports B only as there is no secure path from the parent to
the child.  It will validate as secure by a validator that supports
A+B.

Only when you start enforcing that the TXT and DNSKEY records have
to have matching algorithms in the validator does this break despite
the signer meeting the MUST.

Similarly you can go from A+B to just A by removing the DS records
for A, waiting for the old DS RRset to expire then removing the A
DNSKEYs.

> iEYEARECAAYFAkzmR4UACgkQkDLqNwOhpPh6FACeLAsw/oeIyPpsA4YIL0Bn0jom
> YBoAnRm3491f7m5Y4ipbNc5bpYPNTb6U
> =e/Yn

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Fri, 19 Nov 2010 17:03:11 +0100

Hi Mark,

> signature to validate with.

Right, that is the confusion.

> the child.  It will validate as secure by a validator that supports

Let me explain why I thought it was necessary.  The RFC links the
algorithms in the DS to the algorithms in the DNSKEY.  And the RFC links
the algorithms in the DNSKEY to the algorithms over the data.
Therefore, I did not think it was allowed to link the algorithms in the
DS to the algorithms over the data.  And that you had to check if
algorithms (and thus their signatures) were missing.

If you pick the algorithms from the DNSKEY to see if signatures over
data are missing, then in the above example, a validator that supports
A+B has to mark the answer bogus.

(I happily note as an aside, you can take the subset of algorithms that
is also published in the DS set and do strict-checks with that; this has
safe communication from the parent and more lenient algorithm rollover).

> the signer meeting the MUST.

Another source for this is RFC4641 algorithm rollover (with prepublish
of signatures before key).  I am a bit hazy why the 4641 (and -bis)
documents specify algorithm rollovers with signature introduction, if
this was not necessary; the editors and reviewers had similar confusion?
 I certainly looked at them to make sure they worked when I wrote the
algorithm code.

Best regards,
   Wouter

---

From: Mark Andrews <[email-masked]>
Date: Sat, 20 Nov 2010 12:35:19 +1100

In message <[email-masked]>, "W.C.A. Wijngaards" writes:
> algorithms in the DS to the algorithms in the DNSKEY.

You can only list DS's that cover algorithms in the DNSKEY RRset.
If you don't support one of the algorithms in the DS then the zone
is insecure for that validator.  You don't add the DSs for a algorithm
until max zone TTL has expired from the initial publication of that
algorithm in a DNSKEY RRset.

> And the RFC links the algorithms in the DNSKEY to the algorithms over
> the data.

In a particular version of the zone.

> DS to the algorithms over the data.

We're not yet.  To do incremental introduction of RRSIGs we need
to make that clearer.

> And that you had to check if algorithms (and thus their signatures)
> were missing.

Except there is nothing in RFC 4035 saying to perform this check.
The signer is told to generate them, the validator is not told to
check for them.  Yes this asymetic,  strict sender - liberal receiver
but it allow DNSSEC to work with caches learning data at different
times.  It's also is consistent with any signature validates.

> A+B has to mark the answer bogus.

Which isn't part of the protocol.

I also note that you don't disagree with A only as being secure and
B only as being insecure.  If you are checking algorithm presence
then all should be treated as bogus.

> I certainly looked at them to make sure they worked when I wrote the

RFC4641 doesn't describe algorithm rolls it describes key rollovers within
a algorithm.

Mark

---

From: Jelte Jansen <[email-masked]>
Date: Sun, 21 Nov 2010 11:35:08 +0100

> During the pre-publish period there isn't a trust path into the zone with

no, but during the DS switch there would be, same problem, just a different level.

If it is the DS set that specifies which algorithms are used, you either have to
have both algorithms in that set at one point, or have the zone fully signed
with both algorithms. But if you have both DS's in there, and the zone itself
signed with only one, it'll be bogus for validators that only support the other
algorithm.

But I now notice that the current draft for 4641bis says not to do pre-publish
rollover when switching algorithms, only double signature, so that's ok :)

The part about adding signatures first could probably be removed if 4035 is
clarified (changed, depending on one's POV ;) ) that it is the DS set and not
the DNSKEY set that one should check for algorithm support.

Jelte

---

From: Doug Barton <[email-masked]>
Date: Sun, 21 Nov 2010 13:20:51 -0800 (PST)

I agree with Mark here, and my recollection of the history is the same 
as Mark's and Sam's.

Assume all of the following:
1. Alg(A) is still considered "secure" (validator local policy)
2. There is a DS/DNSKEY/RRSIG chain for Alg(A) in the zone already
3. A new DNSKEY for Alg(B) is added to the zone, but no RRSIGs using 
that key exist (with or without a DS for DNSKEY(B) in the parent).

That situation is NOT a downgrade attack, and should never be considered 
one. (And yes, arguably the authoritative server should not have allowed 
the zone to be loaded, but that's another issue.)

Doug

On Sat, 20 Nov 2010, Mark Andrews wrote:

>> On 11/18/2010 09:16 PM, Ond??ej Sur?? wrote:

-- 

 	Nothin' ever doesn't change, but nothin' changes much.
 			-- OK Go

 	Breadth of IT experience, and depth of knowledge in the DNS.
 	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Mark Andrews <[email-masked]>
Date: Mon, 22 Nov 2010 09:31:52 +1100

In message <[email-masked]>, Jelte Jansen writes:
> If it is the DS set that specifies which algorithms are used, you either have
> to have both algorithms in that set at one point, or have the zone fully
> signed with both algorithms. But if you have both DS's in there, and the
> zone itself signed with only one, it'll be bogus for validators that only
> support the other algorithm.

To roll from one algorithm to another you need to add the new
DNSKEY(s) and sign.  Wait max zone ttl (for all the RRSIGs with
only one set of signatures to clear caches).  Change DS set to
remove the old algorthm and add the new algorith.  Wait DNSKEY TTL
(so there is now no longer a secure path to the zone in any cache).
Removed old algorithm DNSKEY(s) and any signatures made with them.

This is the fastest way to roll from one algorithm to another without
going insecure at somepoint for some validators that support both
algorithms.

You can shorten it (by removing the old DS earlier) but there will
be a time when the zone is insecure for validators that support
both algorithms.

However while this is all happening the validator can be configured
to ignore the old algorithm.  The zone goes immediately to insecure as
far as that validator is concerned on the presumption that insecure is
better than a false secure.

> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkzo9dwACgkQ4nZCKsdOncUYfACgokIBu/FP7JTJr1CiPbzHYpvF
> N8MAnihCFpMwL73cWY+/VFl6E+SdqnoI
> =QPR7

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 22 Nov 2010 09:53:34 +0100

Hi,

> rollover when switching algorithms, only double signature, so that's ok :)

Actually, you cannot even do pre-publish algorithm rollover. In order to
introduce the new algorithm at the parent, you need to fully sign your
zone with that algorithm. Effectively, it becomes a double-signature
rollover.

> the DNSKEY set that one should check for algorithm support.

You would still need to pre-publish signatures if you want to support
RFC 5011 (because you have no method to delay adding this trust anchor
until the zone is fully signed with the new algorithm).

Matthijs

---

From: Jelte Jansen <[email-masked]>
Date: Mon, 22 Nov 2010 10:32:35 +0100

> zone with that algorithm. Effectively, it becomes a double-signature

That's what I was saying; for algorithm rolls: pre-publish bad, double sig good.

> until the zone is fully signed with the new algorithm).

I was trying to carefully tread around the trust-anchor thing until the point
above was cleared out :) But I'm not sure at all why this is (or should be)
different (except that it could take longer)

Jelte

---

From: Mark Andrews <[email-masked]>
Date: Mon, 22 Nov 2010 21:33:14 +1100

> until the zone is fully signed with the new algorithm).

Unless the max zone ttl is greater than the Add Hold-Down timer (min 30 days)
this is a non-issue.

Mark
 
> iQEcBAEBAgAGBQJM6i+NAAoJEA8yVCPsQCW5SnEH/j/gAYWS9xf2+zqgdXHMhTrx
> LHFYQR5HF9SLxmG2gd6HaZ9WpBPge7gTVcnUhP9A7/VLl0LjZdfC83/XFam/X1wZ
> twl4HU6wxwJoVp7xffJKGQkV2by2RUy2Wt+Tz3lY3B0YTGkPC66567Mm/WK/xYT2
> bSUTXaePkrFKuo1d6sg+tM9t14lCBLKoWL79p15UteKm7klIfVCeeVZSm35Rbug0
> XaeSeA3nmlAEAvj24mk1aNCZqZWEjp5zGHKT185Kzrf7sGtxwId5wHto+6y+T58b
> FYEx2f9hBkr6Ww3jMeSNa8DawDx5dUvQKCwwKP8H4//iyg/7SWHb3ksbZ4aHivM=
> =xVvl

---

From: Edward Lewis <[email-masked]>
Date: Mon, 22 Nov 2010 07:58:53 -0500

>the change.  (but not the clarification of signing rules).

Add me to that list.  I think Unbound is not acting in the best 
interests of the network at large.

>zone has these signatures.  They are missing.  Something is wrong.

What is wrong is that Unbound is not adhering to the spirit of 
DNSSEC.  DNSSEC is designed to protect against cache poisoning.  If 
there is a chain of trust to an RRSet, then the set validates, it has 
proven source authenticity and data integrity.

Since time began (for DNS), there is always something wrong 
somewhere.  The goal is a robust system, not a tightly correct system.

>Signatures had been removed from the answer.  To be safe, unbound blocks

I question the use of the word "obvious."  Recall how the TC bit 
works - if a message cannot include all of the required records, the 
message contains what it can.  The receiver has the option to request 
the full answer over TCP or live with what it has already gotten - 
with the chance that what matters was received.

Stripping of records has always been accommodated in the protocol. 
DNSSEC shouldn't forget that.

>Operationally, something really bad is happening.

You do not know that. ;)

>You must not be lenient with security.

Security must be as lenient as possible without allowing badness. 
(If you illegally cross the street, should the police track you down, 
arrest you, question you, etc., if there was no other record than a 
CCTV image?  Sorry, I hate analogies.)

>actual security benefit to this policy?

You aren't violating a specific RFC but you are causing "false 
positive" situations.

>Yes, people should know how to keep it signed properly.

Remember, there is more than a signer and authority involved, there 
are caches, etc.  The big cooperative Internet and all that. 
End-to-end principle.

>I do not agree with this, because it diminishes security.

Security isn't the goal - robustness, resiliency, and response is. 
(Think about that one for a while.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Ever get the feeling that someday if you google for your own life story,
you'll find that someone has already written it and it's on sale at Amazon?

---

From: Edward Lewis <[email-masked]>
Date: Mon, 22 Nov 2010 09:48:52 -0500

Apologies for not thoroughly reading the thread (volume is 
overwhelming), but I wanted to send this which I sent privately to 
Ondrej.  The reason is that I don't think anyone has properly stated 
the "use case" that prompted the questioned text.  (E.g., it isn't 
about algorithm "strength".)

Using a proof-by-contradiction approach, let's assume a signer *does 
not* have to have a signature by every algorithm at each and every 
set.

Let's say a signer has an alg 5 and alg 8 key in DS/DNSKEY and 
decides to signs all sets owned by names from a-m with alg 5 and all 
others with alg 8.  This decision is not expressible in the protocol 
(meaning the signer can't signal this to the verifier).

Let's say a verifier has implemented alg 5 but not alg 8.  When it 
asks for a set beginning with "a" it is supposed to arrive with a 
signature of alg 5.  The verifier should be able to validate the set. 
We know that only because we have "above vision" - knowing the intent 
of the sender.

If the verifier gets the set desired but there is an alg 8 signature 
there and no alg 5 signature, the verifier has no choice but to 
accept the data, even if the data has been forged.  Without the 
knowledge that the signer must have alg 5 and alg 8 signatures at the 
set, the verifier would be correct to conclude that this set was 
signed only by 8 and not by 5, thus out of bounds for the verifier.

The problem is, we know that the set was signed only by alg 5.  What 
happened is an interloper stripped off the legitimate alg 5 signature 
and inserted a completely bogus alg 8 signature - perhaps merely by 
changing the 5 to an 8 - and changing the data (maybe).  Recall that 
the verifier has not implemented alg 8 and hence cannot determine 
that the signature is bogus.

So, because the verifier is in an undecidable position - it can't 
distinguish between properly signed by alg 8 or improperly stripped 
of an alg 5, we have to require the signer include both.  The intent 
of this rule is to allow the verifier to have a "right to expect" an 
algorithm it can handle (given that the algorithm is in the DS and 
DNSKEY sets).  The intent was never to "look for trouble" in the 
sense that Unbound does.

- In summary, what we were concerned about was supporting old 
resolvers that didn't know about some algorithms, not a choice of 
algorithm situation.  And we were trying to make sure the protocol 
had a sufficient specification because we couldn't convey policy 
in-band.

- What the text missed was we didn't properly account for caching 
behavior and transition states.  (The latter a genetic problem in 
IETF solutions.)

- Oh, and yes, we probably could scope the requirement to the set of 
algorithms with keys that have an SEP bit set.

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 22 Nov 2010 17:47:08 +0100

> that key exist (with or without a DS for DNSKEY(B) in the parent).

I don't think you can mix the "with or without".  If you publish DS for 
DNSKEY(Alg(B)) you must have signatures created by DNSKEY(Alg(B) in the 
zone (ie. double sign over all your zone).

---

From: Paul Vixie <[email-masked]>
Date: Mon, 22 Nov 2010 17:33:29 +0000

> Date: Mon, 22 Nov 2010 07:58:53 -0500
> From: Edward Lewis <[email-masked]>
> ...
> DNSSEC is designed to protect against cache poisoning.  If there is a chain
> of trust to an RRSet, then the set validates, it has proven source
> authenticity and data integrity.
> 
> Since time began (for DNS), there is always something wrong somewhere.  The
> goal is a robust system, not a tightly correct system.

+1.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Tue, 30 Nov 2010 11:43:23 +0100

Hi workgroup,

The unbound implementation is the way it has been written, and I agree
that changes have to be made to it.  Now, what is the right way?

>> goal is a robust system, not a tightly correct system.

It would be good to have some text in bis-updates on this.  (I mean on
the algorithm topic, the general leniency has been put forward by Alfred
and others and I wholeheartedly agree with it :-) ).

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.  (so this is what Mark was
proposing).  This is what validators use to determine if they can
support the algorithms present in the zone today (and tomorrow).

However, there are choices that I see here, that change the security
properties.

* One Signature Is Enough

Check one signature, if it works, it's enough, and the added text is
'regardless of the algorithms signalled in the DS-set'.
+ it is lenient.
  (it would have avoided the operational problems that incited this).
+ if a zone is badly signed, so it includes algorithms in the DS set for
which proper signatures are not available, the validators that support
both algorithms approve of this situation.
- - no algorithm-protection (explanation below).

* Check the Algorithms

For the algorithms signalled in the DS set, check that there is a valid
chain of trust for them.  Added text is, the validator SHOULD or MUST
check (choice here) that the algorithms signalled in the DS-set work
(but only for algorithms supported by the validator, of course).

+ it is lenient because uses DS-set not DNSKEY-set.
  (this allows the easier algo rollovers; it would have avoided the
operational problems that incited this).
- - but not as lenient as 'one signature', this is the case of zones that
are badly signed but have signalled the algorithm with their DS, so that
a portion of validators are certain to fail for it.  Validators that
support the other algo now also fail for it.
+ algorithm protection (explanation below).
  + if SHOULD, local-policy decides what protection to apply.

Algorithm compromise protection.
This is a security property that the validation result can have or not.
 Security algorithms have different properties, and by checking them you
receive joined benefits.  Specifically, if one algorithm is 'broken'
(but you do not yet know which one that will be), then you are protected
against this because you check the other algorithm.

For zones that perform a single-DS rollover, this never applies, as the
single DS makes validators check one algorithm anyway (since this
minimizes communication with the parent, many zones can be envisioned to
do this).  Other zones may have multiple DSes (or DLVs) and thus can
have multiple crypto algorithms checked, at their option (and the
validator local policy).

I would like to know what the (seems rough) consensus is, so that I can
go forward and implement this right.  It is then a good idea that Sam
puts conclusions in the dnssec-bis-updates draft.

Best regards,
   Wouter