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

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


The add hold down time is meant to provide some breathing room for the owner against an attacker adding a new trust anchor.  If the attacker holds only one key (B), and the owner doesn't revoke it, then eventually the attacker can add a new trust anchor (C).  The incantation for the attacker is "B and C sign (B C X)" where X is a ZSK key owned by the attacker.   The moment that the owner sees something it hasn't itself signed, signed with B, then the owner should issue "A and B sign (A, Br, D, Z)" where D is the owner's replacement for B and where Z is a ZSK key owned by the owner.

Any SEP key can become a trust anchor if it is validly signed and is in the DNSKEY RRSet for the add hold down time (plus one retrieval).




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

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.
>> 
>> 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 can't help it if they don't read the black and white text of 5011.  



>   A key is considered revoked when the resolver sees the key in a
>   self-signed RRSet and the key has the REVOKE bit (see <http://tools.ietf.org/html/rfc5011#section-7>Section 7
>   below) set to '1'.  Once the resolver sees the REVOKE bit, it MUST
>   NOT use this key as a trust anchor or for any other purpose except to
>   validate the RRSIG it signed over the DNSKEY RRSet specifically for
>   the purpose of validating the revocation.  Unlike the 'Add' operation
>   below, revocation is immediate and permanent upon receipt of a valid
>   revocation at the resolver.



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


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


In practice, it may take a little time to get folks together for the key ceremony for C, so you may end up with an interim DNSKEY RRSet "A and B sign (Ar B Z)" for a few days.  [Which by itself suggests a need to be able to do signatures without having everyone physically present]


In the above, the attacker's only ploy is to do "A signs (A N X)" where N is a new trust anchor key owned by the attacker and X is a new ZSK also owned by the attacker.  His hope is that the validly signed (by compromised key A) RRSet gets accepted for a short while by specific targets and maybe long enough to get a new trust anchor key accepted by those specific targets.


>--Paul Hoffman

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