Re: How are people implementing hold-down in RFC 5011?

At 01:13 PM 10/7/2014, Paul Hoffman wrote:
>Greetings. In reading RFC 5011 more carefully, I am finding that some of the wording is confusing (possibly just to me). I have a few questions for people who have implemented it in systems, but also want to hear from the greater DNS community.
>
>Section 2.2 says:
>
>   Assume two trust point keys A and B.  Assume that B has been
>   compromised.  An attacker could generate and add a new trust anchor
>   key C (by adding C to the DNSKEY RRSet and signing it with B), and
>   then invalidate the compromised key.  This would result in both the
>   attacker and owner being able to sign data in the zone and have it
>   accepted as valid by resolvers.
>
>I am assuming that "invalidate" means "revoke". 

Yes.  

>Pictorially, I think this means the following progression in time:
>   1: Owner's zone: A signs (A B)
>   

1.5 Attacker's zone: B signs (B C)
(This has to happen for the Add Hold down time until C becomes a valid trust anchor.  In general this is going to be B and C sign (B, C) for the hold down period).

>2: Attacker's zone: B signs (A Br C)
>(Here, "Br" means "B with the REVOKE bit set".)

2 is actually B and C sign (Br C).

>Immediately after the relying party has seen (2), B can never be trusted again, even while they are waiting for the hold-down timer for adding C.

Revocation takes place immediately.  Once the bit is set and validly signed, the key is revoked and can't be used for anything except signing the revocation.  So in B and C sign (Br C), the signature over the keys by B only has impact on Br,  The signature by C over the keys only has impact if C has already been added to the validators trust anchor set.


>Later in Section 2.2, it says:
>
>   In the given example, the zone owner can recover from a compromise by
>   revoking B and adding a new key D and signing the DNSKEY RRSet with
>   both A and B.
>
>The time progression here sounds like:
>   1: Owner's zone: A signs (A B)
>   2a: Attacker's zone: B signs (A Br C)
>   2b: Owner's zone: B signs (Br) and A signs (A D) and B signs (A D)
>2a happens before 2b because that is how the owner discovers that B was compromised.

What happens at a validator depends on what the validator sees.  In general this goes:

A Signs (A B)
B is compromised
Owner:  A and B sign (A Br D) - B is revoked and D starts its process of being added as a trust anchor.
Attacker:  B signs (B C)

The key point is that if the validator sees even one of the "A and B sign (A Br D)" RRSets, then B is revoked and "B signs (B C)" will fail validation leading to C not being added to the trust anchor set.


>I don't understand why B signs (A D) in 2b. B is already untrusted to anyone who saw 2a, and is untrusted by anyone looking at all of 2b. These instructions seem to be saying "put a signature into the zone that cannot be validated". I would think that 2b should just be "B signs (Br) and A signs (A D)", but that's not what the RFC says.

You can't actually have two different versions of the DNSKEY RRSet being simultaneously offered by a single responder.  You *can* have multiple signatures over a single DNSKEY RRSet.

So the above is actually "A and B sign (A Br D)".  It's also actually more like "A and B sign (Br D and Z)" where "Z" is one of the ZSKs.  So you get "B signs Br to revoke itself", "A signs D to add D to the trust anchor set" and "A signs Z so that Z chains to the root of trust".  

That's expressed by a DNSKEY RRSet consisting of B with the revoke bit, D with the SEP bit and Z without the SEP bit with two RRSIG(DNSKEY) records consisting of a signature by A and  a signature by B.

Mike




>So: has anyone implemented what the RFC says? If so, did you try it with some validating resolvers? What were the results?
>
>Or: am I completely misreading something in this section?
>
>--Paul Hoffman
>_______________________________________________
>dnsext mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/dnsext


_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext