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

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.

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

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

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


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

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

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


Best regards,
   Matthijs

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

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