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

On 13-10-14 17:58, Michael StJohns wrote:
> 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.

The scenario above is for the attacker, he has no incentive of keep 
publishing A.


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

Correct.


>>> 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
> resolvers]

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



>
> Mike
>
>
>
>
>
>
>> Best regards, Matthijs
>
>

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