Re: How are people implementing hold-down in RFC 5011?
Matthijs Mekking <mmekking <at> dyn.com>
2014-10-13 08:59:54 GMT
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.
I have implemented this (http://nlnetlabs.nl/projects/autotrust/) and I
agree with Michael's interpretations (even if it was after an hour
asking questions at some past IETF).
I am trying to clarify below, although most stuff seems already
>> On Oct 7, 2014, at 1:03 PM, Michael StJohns <mstjohns <at> comcast.net> 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).
All above seems pretty clear.
>> >> 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
> 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.
> 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.
>> >> 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.
>> > 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
>> Section 7 <http://tools.ietf.org/html/rfc5011#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
>> >> 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 <mstjohns <at> comcast.net> 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
> 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)"
> 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)".
> 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
> dnsext <at> ietf.org
dnsext mailing list
dnsext <at> ietf.org