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

At 04:59 AM 10/13/2014, Matthijs Mekking wrote:
>Hi,
>
>On 09-10-14 18:46, Michael StJohns wrote:
>>At 07:57 PM 10/7/2014, Paul Hoffman wrote:
>>>Thanks for the clarifications. I still have a bunch of questions, and
>>>I really do wonder if implementers agree with your interpretations.
>
>
>>>>
>>>>> 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.
>>
>>That's not actually a matter of concern for the zone owner. The
>>incantation to revoke a key K is "K signs (Kr)".  As I noted elsewhere,
>>you can't actually have multiple disjoint DNSKEY RRSets for a given
>>name, so that you end up doing a union of all the keys to be signed into
>>a single DNSKEY RRSet and you provide signatures by all signers over all
>>the keys.
>
>When the RFC says "and signing it with B" in section 2.2 Add Hold-Down, it talks about adding C to the DNSKEY RRset. C is still a stand-by key and does not necessarily need to sign the DNSKEY set. C will still be added to the validator in the AddPend state.
>
>When B is revoked, you do want to sign with both B and C: B to self-sign (Br) and C to sign the DNSKEY RRset.

It depends.  If A is still sacrosanct - then the usual incantation for the owner will be  "A and B sign (A Br C Z)" where C is a new trust anchor and Z is the ZSK.    C becomes a standby trust anchor and doesn't have to actually sign the root DNSKEY RRSet until it's placed into active service.

For the attacker, trying to add a new trust anchor that he owns (N), the incantation is going to be "B and N sign (B N X)" where X is a ZSK owned by the attacker.

The attacker - if all he holds is B - can't sign Br until after the Add Holddown period expires if he's trying to add a new attacker owned trust anchor.



>>With respect to the relying party - he doesn't know and can't tell - who
>>originated the DNSKEY and signature data he's seeing.  It's a crap shoot
>>as to which version of the "truth" (owner or attacker) he sees.  The
>>5011 model is designed to make it as difficult as possible for an
>>attacker to feed its version of truth to a specific validating resolver
>>for a long enough period of time so that resolver installs a new trust
>>anchor AND never sees the revocation of the compromised trust anchor.
>>
>>
>>>>> 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.
>
>I think the time progression is as follows:
>
>1a:  Owner's zone: A signs (A B)
>1b:  Attacker's zone: B signs (B C)
>2a:  Owner's zone: A and B signs (A Br D)
>2b:  Attacker's zone: B and C signs (Br C)
>
>The owner should do step 2a before the attacker is able to do 2b.


Right, but 2a can happen as soon as the owner notices something hinky with the zone or suspects a compromise.  2b can't happen until 1b has been out in the wild for the entire Add Holddown time otherwise the attacker is throwing away its only mechanism for installing new trust anchors.




>>Yes, D is the owner's replacement for B.    I don't name the keys as "C"
>>and "D" in section 6.1, but that's what's happening.
>>
>>You used "C" as the "Attacker's new trust anchor" in this series of
>>messages.  I probably would have used something more disjoint in the
>>explanation.
>>
>>
>>So to clarify.
>>
>>1) Start with two trust anchors (A B) and a ZSK (Z) (let Z stand for any
>>of the regularly generated ZSKs)
>>2) B is a stand by key - it's a trust anchor, but not used for regular
>>quarterly signing
>>3) The normal DNSKEY RRSet is "A signs (A Z)"
>
>Since B is a standby key, it should be "A signs (A B Z)"


No.  Once B is added as a trust anchor, it need not be included in the root DNSKEY RRSet.   If B is not signing anything, there is no reason to include it.


>>4) If A or B is compromised then generate a new key pair C
>>5) Assuming A is compromised issue a new RRSET  "A and B sign (Ar B C
>>Z)"  and propagate that for twice the add hold down time.  (the add hold
>>down time to get the bits set, the additional time to pick up stragglers
>>- the additional time is just suspenders and belt)
>>6) Once you've done (5) for long enough, issue a new "normal" RRSET "B
>>signs (B Z)".  C is now a standby key.
>
>6) should be "B signs (B C Z)".


Same thing as above.  Once C is a trust anchor, unless its actively signing something, there's no need to include it in the DNSKEY RRSet.  [However, you increase the "take" rate for resolvers the longer you leave it there - especially if there are intermittently connected resolvers]

Keys enter the trust anchor set only by being present in the root DNSKEY RRSet and signed by a previous trust anchor for a minimum period of time (the Add Hold Down).   Keys leave the trust anchor set only through revocation.   

Mike






>Best regards,
>  Matthijs


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