Re: [dnsext] Clarifying the mandatory algorithm rules

["W.C.A. Wijngaards" <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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).

On 11/18/2010 12:02 PM, Samuel Weiler wrote:
> opening resolvers to a downgrade attack or discouraging the use of new
> algorithms.

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.

> 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.

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.

> 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

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.

> 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.

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?

> 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.

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

> 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.
> 
> I'm not sure if the generalization (that validators can ignore section
> 2) is 100% correct.  Is it?

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.

> 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:

Perhaps the above paragraph can be shortened, 'rules are restated 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.

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.

> 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."

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

> 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.

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkzlEpMACgkQkDLqNwOhpPhjYACeMfS3m7QSRRolK48EhaigyRuS
RBgAoLH+zQ+VN36QoaJaHjlU9uPJLEay
=vjRC
-----END PGP SIGNATURE-----