Subject: [DNSOP] new dnsop related draft: RFC5011 security considerations

From: Wes Hardaker <[email-masked]>
Date: Mon, 01 Aug 2016 15:00:52 -0700

The following draft, authored by Warren and I, might be of interest to
the dnsop crowd:

https://tools.ietf.org/html/draft-hardaker-rfc5011-security-considerations-00

[it currently does not have a home]
-- 
Wes Hardaker
Parsons

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 1 Aug 2016 22:29:51 +0000

Very nice draft.

>    RRSIG Signature Validity  10 days

Here I think you probably want to say DNSKEY RRSIG signature validity, because thats the only RRset whose validity period matters, right?

>  Zone Maintainer  The owner of a zone intending to publish a new Key-
>     Signing-Keys (KSKs) that will become a trust anchor by validators
>     following the RFC5011  process.

Could I convince you to use another term?  Maybe just Zone Owner?  I worry that when people read Zone Maintainer they would subconsciously put "Root" in front of it and your abstract notes that this isn't really a concern for (current) root zone plans. 

DW

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 01 Aug 2016 15:54:01 -0700

"Wessels, Duane" <[email-masked]> writes:

> Here I think you probably want to say DNSKEY RRSIG signature validity,
> because thats the only RRset whose validity period matters, right?

Very good point.  Changed for our next publication.

> Could I convince you to use another term?  Maybe just Zone Owner?  I
> worry that when people read Zone Maintainer they would subconsciously
> put "Root" in front of it and your abstract notes that this isn't
> really a concern for (current) root zone plans.

Sure.  Though there is always an issue with coming up with terms to
describe who controls various bits of a zone these days.  It's not the
content owner, as that's often separated from the security dude that
signs the content (as you well know).  We need a suitable term for that
role generally.  I particularly like a suggestion by thesaurus.com, and
sadly it's actually the better of many of the choices: "zone right-hand
person".

Any other suggestions?
-- 
Wes Hardaker
Parsons

---

From: Bob Harold <[email-masked]>
Date: Tue, 2 Aug 2016 09:44:09 -0400

On Mon, Aug 1, 2016 at 6:54 PM, Wes Hardaker <[email-masked]> wrote:

> "zone signer" for that role?

Some typos:

 1.  Introduction
"indented"  should be "intended"

5.  Denial of Service Attack Considerations
"validataor" should be "validator"

-- 
Bob Harold

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 02 Aug 2016 08:15:47 -0700

> "zone signer" for that role?

That could probably work.

> "validataor" should be "validator"

Fixed, thank you!

(the draft is far from done, but catching those early is always a good thing)
-- 
Wes Hardaker
Parsons

---

From: Shane Kerr <[email-masked]>
Date: Wed, 3 Aug 2016 13:58:19 +0200

Wes,

At 2016-08-01 15:00:52 -0700

> [it currently does not have a home]

Reading this document it basically seems like the hold-down timer is
actually a potential for mischief, rather than a good thing. There is
no mitigation recommended, right? I can't think of a fix that doesn't
involve protocol changes.

My own feeling is that the hold-down timer is tricky operationally, and
adds no actual value. I'd support using your draft as the basis of a
proposal to deprecate the hold-down timer completely.

Cheers,

--
Shane

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 3 Aug 2016 14:24:17 +0200

Shane,

> proposal to deprecate the hold-down timer completely.

The Add Hold-Down time adds value in the form of some mitigation against
automated configuration of a compromised trust anchor in the resolver.

While not waterproof, I don't think we should abandon the Add Hold-Down
timer, although the long time may be somewhat of a burden and
the outlined Denial of Service attack is to be taken serious.

I would rather see a mitigation against the replay attack by for example
adding a jitter to the Active Refresh, to make the query interval less
predictable.

Best regards,
  Matthijs

> 
> Cheers,
> 
> --
> Shane
> 
> 
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 3 Aug 2016 14:44:31 +0200

Hi Wes, Warren,

> [it currently does not have a home]

Thanks for this document. Two comments:

1. In the introduction you mention there is no guidance to how long a
DNSKEY must be published before it can be considered accepted. Perhaps
there is no implicit guidance in RFC 5011, you should be able to derive
it from the timing parameters defined in that document. In fact, it has
been done before and RFC 7583 (DNSSEC Key Rollover Timing
Considerations) gives guidance on exactly this in Section 3.3.4.

2. The outlined attack is possible because the defined queryInterval is
approximately done at the half of the RRSIG expiration interval. If the
queryInterval was to be increased that it would be at most the full
expiration interval, the replay attack cannot be successfully executed.
While this makes the DNSKEY rollover duration even longer, it is now
secured against the outlined attack.

Best regards,
  Matthijs

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 03 Aug 2016 10:22:55 -0700

Shane Kerr <[email-masked]> writes:

> actually a potential for mischief, rather than a good thing.

No, it's a useful thing (per the discussion in 5011 itself as to its
purpose).  The problem is that the length hold-down timer (used at the
5011 validator) does not equal the length of time the publisher must way
before switching keys.  5011 only provides guidance for the validator,
but leaves out the information to be used by the publisher.  Thus, 5011
is really half the document it needs to be and the missing half can
cause security implications if you can't self-derive the values.  And
judging buy our survey of experts, I don't think the average Joe will
pick a safe value (hence the need for the document).
-- 
Wes Hardaker
Parsons

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 03 Aug 2016 10:38:05 -0700

Matthijs Mekking <[email-masked]> writes:

> it from the timing parameters defined in that document.

I believe one can derive it, hence the reason we titled the draft
"security considerations".  IE, it's not the intent of the draft to
create anything new, just to more clearly document what is already true
(but misunderstood by most).

> In fact, it has been done before and RFC 7583 (DNSSEC Key Rollover
> Timing Considerations) gives guidance on exactly this in Section
> 3.3.4.

I need to study that document again (it's been a while) in order to
fully respond to your note, but I agree there is information in there
that is certainly relevant.  And we should certainly add a reference to
it as well, if this document needs to go forward.

In 3.3.4.1, we have:

    modifiedQueryInterval = MAX(1hr, MIN(15 days, TTLkey / 2))
    Itrp >= AddHoldDownTime + 2 * modifiedQueryInterval

And in our document, I just realized, fails to define the "safe"
equation that we came up with.  But our safe value came out to be:

    Itrp >= AddHoldDownTime + 3 * SignatureLife / 2 + 2 * TTLkey

We'll go add that equation into our document (which I was sure we had
put in, but apparently not) and republish shortly.

> secured against the outlined attack.

I don't think we need to modify 5011 itself.  Just how to use it.

-- 
Wes Hardaker
Parsons

---

From: Michael StJohns <[email-masked]>
Date: Wed, 3 Aug 2016 14:10:11 -0400

> [it currently does not have a home]

I went off and thought about this for a while and came up with:

1) The absolute earliest time that the FIRST resolver would install a 
new trust anchor:  publicationTime + holdDownTime

2) The absolute earliest time that the PUBLISHER can assume that the  
FIRST resolver has installed the new trust anchor: (latestExpirationTime 
of all DNSKey RRSets that do not contain KNew  or publicationTime 
(whichever is later) ) + holdDownTime

3) The time when a publisher can assume reasonable numbers of resolvers 
have installed the new trust anchor (and incidentally the period in 
which they should avoid revoking the keys being used to add the new 
trust anchor):  Some time after (2) depending on how much penetration 
you want and making wild guesses about things like off-line resolvers 
rejoining the internet after being away.    So I think this is related 
specifically to the original TTL. So maybe this is

latestExpiration + holdDownTime + N*MAX(any originalTTL published in the 
DNSKEY RRSig record over the new key) where N is >= 2. But this is no 
better than a SWAG at the numbers.

For the current root key rollover stuff, I think 3 months is a pretty 
good SWAG.

The above doesn't actually change the basic model of DNS as an 
incoherent data protocol.   The time from publication to acceptance by 
an individual client of any published data varies drastically from the 
acceptance of that same data by a different client at a different place 
in the network with different query patterns.  If a new NS record were 
added to the root tomorrow, we wouldn't expect the entire world to pick 
that up immediately and we would expect that there would be some time 
until a large percentage of resolvers would know about the new NS and 
start using it.  That incoherence time would be related to the time it 
takes to propagate the NS records to the other root servers and for TTLs 
to expire on the existing data and the actual liveness of the resolvers.

Why this calculation should be very different for the root DNSKEY RRSet 
escapes me.

Mike

---

From: Warren Kumari <[email-masked]>
Date: Wed, 3 Aug 2016 12:20:30 -0700

> put in, but apparently not) and republish shortly.

Yup, somehow the equation section ran away during edits of the initial
version -- Wes and I hunted it down, put it back in the document and
it's been posted.

Hopefully it is clearer now.
W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 4 Aug 2016 10:37:12 +0200

Wes,

>     Itrp >= AddHoldDownTime + 2 * modifiedQueryInterval

Looking at this advice again, I think the Zone Maintainer in the
outlined attack actually even makes a conservative assumption about when
it is safe to use the new key (T-36). If the Zone Maintainer followed
the guidance in Section 3.3.4.1 from RFC 7583, it would have at least
waited Itrp.

The AddHoldDownTime is 30 days already in your example, see RFC 5011:

   The add hold-down time is 30 days or the expiration time of* the
   original TTL of the first trust point DNSKEY RRSet that contained the
   new key, whichever is greater.

* Side tracked: This 'of' should probably be an 'or'. Or I don't know
what 'the expiration time of the original TTL...' means.

The modifiedQueryInterval in your example is

    MAX(1hr, MIN(15 days, 1d /2)) = MAX(1hr, 1/2 day) = 1/2 day

So already at T-31 the Zone Maintainer could have believed that all 5011
enabled validators should have accepted the new key.

Now RFC 7583 makes this remark:

   Once
   retrieved, a validating resolver needs to wait for AddHoldDownTime.
   Providing it does not see a validly signed DNSKEY RRset without the
   new key in that period, it will treat it as a trust anchor the next
   time it retrieves the RRset, a process that can take up to another
   queryInterval (the third term).

So Itrp does indeed not take into account this attack possibility.

>     Itrp >= AddHoldDownTime + 3 * SignatureLife / 2 + 2 * TTLkey

Which in this example is 30 + 15 + 2 = 47 days.

Since the replay attack is not possible anymore after the signatures at
T-1 (or before) are expired, I think the new Itrp should be:

      Itrp >= SIGVALkey + AddHoldDownTime + 2 * modifiedQueryInterval

...where SIGVALkey is the RRSIG Signature Validity period of the DNSKEY
RRset, used at T-1.

> I don't think we need to modify 5011 itself.  Just how to use it.

True. It's a matter of how one wants to fix it: With zone management to
deal with the attack, or with updating the protocol so the attack cannot
take place.

I think the latter is more robust, but it's certainly good advice to
increase the publication time of the DNSKEY to circumvent the attack.

Best regards,
  Matthijs