Re: How are people implementing hold-down in RFC 5011?
Matthijs Mekking <mmekking <at> dyn.com>
2014-10-14 08:49:56 GMT
On 13-10-14 17:58, Michael StJohns wrote:
> At 04:59 AM 10/13/2014, Matthijs Mekking wrote:
>> 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.
The scenario above is for the attacker, he has no incentive of keep
> 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
>>>> 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.
>> 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
>>> 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.
That depends on your key rollover mechanism. In the Double-DS rollover,
you don't need to add B, in Double-KSK and Double-Signature you do.
But if you want B to keep as a trust anchor at the validator, you better
leave it in the DNSKEY RRset, otherwise it goes to the `Missing` state,
an abnormal state. That can't be good.
In the Autotrust implementation, missing trust anchors will be removed
after a (fairly long) time, otherwise we might end up with a bunch of
valid, but missing, trust points which are no longer in use. That sounds
like a weakness in the system.
>>> 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
Same thing as above. You want to keep it in the DNSKEY RRset, or the
validator will mark the trust anchor as `Missing`.
> 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.
Right, and to me that sounds like a weakness. Missing trust points
should be cleaned up too.
>> Best regards, Matthijs
dnsext mailing list
dnsext <at> ietf.org