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

Thanks for the clarifications. I still have a bunch of questions, and I really do wonder if implementers agree with your interpretations.

On Oct 7, 2014, at 1:03 PM, Michael StJohns <[email protected]> wrote:

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

There is nothing in the quoted paragraph from the RFC that indicates that the attacker gets C to be a valid trust anchor. It sounds like you meant to say "the attack is only going to work if a relying party trust C, and that will only happen after the hold-down period, so the attacker first introduces C, then only that has succeeded for some desired targets, revokes B".

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

When the RFC says "and signing it with B", it might be clearer if it says "and signing it with B and C". It is far from clear which messages from the attacker are for public consumption (which would be seen by the zone owner) and which are meant for restricted relying parties. 

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

Yup.

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

Yes, that's clearly the intent, and it should work (assuming that the resolver follows the "revoke B as soon as you see a B-signed-Br anywhere" rule).

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


On Oct 7, 2014, at 1:10 PM, Michael StJohns <[email protected]> wrote:

> Sorry - 
> 
> This is actually "A and B sign (A Br D and Z)".
> 
> A signing key needs to be included in the DNSKEY RRSet even if its already accepted as a trust anchor.  That's mainly so the key id reference of the RRSIG (DNSKEY) can find the appropriate public key for validation. 

Why D? Is it a replacement for B because 5011 works better with more than one trust anchor? I didn't see anything in the section that explained D, and from what you say above, it looks like I guessed wrong the first time.

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