Subject: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-00.txt

From: [email-masked]
Date: Tue, 04 Apr 2017 05:04:28 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.

        Title           : Security Considerations for RFC5011 Publishers
        Authors         : Wes Hardaker
                          Warren Kumari
	Filename        : draft-ietf-dnsop-rfc5011-security-considerations-00.txt
	Pages           : 9
	Date            : 2017-04-03

Abstract:
   This document describes the math behind the minimum time-length that
   a DNS zone publisher must wait before using a new DNSKEY to sign
   records when supporting the RFC5011 rollover strategies.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-rfc5011-security-considerations-00
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5011-security-considerations-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Bob Harold <[email-masked]>
Date: Tue, 4 Apr 2017 16:28:06 -0400

> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5011-security-
This one still needs to be fixed:

----------
"6. Minimum RFC5011 Timing Requirements
...
The most confusing element of the above equation comes from the "3 *
   (DNSKEY RRSIG Signature Validity) / 2" element, but is the most
   critical to understand and get right."
-----------

But the equation no longer contains "3 * " anywhere.

-- 
Bob Harold

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 06 Apr 2017 15:34:45 -0700

> This one still needs to be fixed:

Thanks Bob.  That was a straight copy; I hope to do a new 
version immediately and will certainly make that change.
-- 
Wes Hardaker
USC/ISI

---

From: Daniel Migault <[email-masked]>
Date: Thu, 13 Apr 2017 13:54:03 -0400

Hi,
Please find some comments I have quickly written as reading the draft.

Yours,
Daniel

             Security Considerations for RFC5011 Publishers
          draft-ietf-dnsop-rfc5011-security-considerations-00

5.  Denial of Service Attack Considerations

   If an attacker is able to provide a RFC5011 validating engine with
   past responses, such as when it is in-path or able to otherwise
   perform any number of cache poisoning attacks, the attacker may be
   able to leave the RFC5011-compliant validator without an appropriate
   DNSKEY trust anchor.  This scenario will remain until an
   administrator manually fixes the situation.

MGLT: While reading the paragraph above, it is not obvious to the reader
that the remaining section will clarify this. I think equivalent o fthe
sentence below would be appreciated.

   The following timeline illustrates this situation.

5.1.  Enumerated Attack Example

   The following example settings are used in the example scenario
   within this section:

MGLT: I think it would be helpful to define variable, that we could easily
refer in the text. As time values are expressed in seconds, I would also
suggest that time is expressed in seconds even though we should use human
readable expressions for the time. More specifically, I would have T-1 be
expressed as T-1day and T-1 representing T-1 second.
Maybe that would also ease to match the signaling to use Signature
Expiration Date instead of DNSKEY RRIG Validation.
I was also confused by the Validation of 10 days. My understanding was that
data signed at T were valid until T + 10, and in the description below, it
seems that data signed at T - 1 are valid until T + 10. In my opinion this
is more T + 9. But I might be wrong.
I also think that the use case here relies on strong assumption. One of
them is that the zone is generated with mostly fields with the same value.
In other words, there is no consideration of having TTLS values, Signature
Expiration updated during the roll over.
As the zone is generated every day, maybe that would help the description
by indexing the data for each day, thus making it clear this field
generated at this day.

OLD:
   TTL (all records)  1 day

   DNSKEY RRSIG Signature Validity  10 days

   Zone resigned every  1 day
NEW:

   TTL designates the minimum TTL value associated the DNSKEY, RRSIG
RRsets. According to RFC4034 section 3, the TTL of the DNSKEY and the one
of the RRSIG are the same.

   Signature Expiration Date designates the date after which the signature
cannot be used for DNSSEC validation. RFC4034 section 3.1.5

   Signature Inception Date designates.... RFC4034 section 3.1.5 OPTIONAL

This section provides an illustrative example and assumes:
    - Only static values are used. In other words, there is no dynamically
increaseing, decreasing TTLs or Expiration Date.
    - A single TTL value is used for both KSKs. In the general case we
could have different values of TTL. This value is set here to 1 day.
    - The zone is signed every day at time T.
    - Each day the Expiration day is set to T + 10 days

   Given these settings, the following sequence of events depicts how a
   Trust Anchor Publisher that waits for only the RFC5011 hold time
   timer length of 30 days subjects its users to a potential Denial of
   Service attack.  The timing schedule listed below is based on a new
   trust anchor (a Key Signing Key (KSK)) being published at time T+0.
   All numbers in this sequence refer to days before and after such an
   event.  Thus, T-1 is the day before the introduction of the new key,
   and T+15 is the 15th day after the key was introduced into the
   fictitious zone being discussed.

   In this dialog, we consider two keys being published:

   K_old  The older KSK being replaced.

   K_new  The new KSK being transitioned into active use, using the
      RFC5011 process.

   In this dialog, the following actors are playing roles in this
   situation:

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

   RFC5011 Validator  A DNSSEC validator that is using the RFC5011
      processes to track and update trust anchors.

Hardaker & Kumari        Expires October 5, 2017                [Page 4]

Internet-Draft       RFC5011 Security Considerations          April 2017

   Attacker  An attacker intent on foiling the RFC5011 Validator's
      ability to successfully adopt the Zone Signer's K_new key as a new
      trust anchor.

5.1.1.  Attack Timing Breakdown

   The following series of steps depicts the timeline in which an attack
   occurs that foils the adoption of a new DNSKEY by a Trust Anchor
   Publisher that revokes the old key too quickly.

 MGLT: T-1, are mostly indexing the zone, maybe that easier to start from
this set.

   T-1  The last signatures are published by the Zone Signer that signs
      only K_old using K_old.  The Attacker queries for, retrieves and
      caches this keyset and corresponding signatures.

MGLT: Maybe we could clarify the state of the cache. This can be done until
(T-0day) - 1 seconde, which means RRSIG will be considered valid until
Expiration Date = T - 0 days + 10 days while K_old will be considered valid
for TTL, that is until T + TTL - 1.

   T-0  The Zone Signer adds K_new to his zone and signs the zone's key
      set with K_old.  The RFC5011 Validator retrieves the new key set
      and corresponding signature set and notices the publication of
      K_new.  The RFC5011 Validator starts the (30-day) hold-down timer
      for K_new.

   T+5  The RFC5011 Validator queries for the zone's keyset per the
      Active Refresh schedule, discussed in Section 2.3 of RFC5011.
      Instead of receiving the intended published keyset, the Attacker
      successfully replays the keyset and associated signatures that
      they recorded at T-1.

MGLT: The keyset at T-1day is also the keyset at T-0 day - 1 sec. I believe
the text should make clear there is an interval. As the expiration time has
been set to T - 1 + 10 days. These data are still considered valid at T +
5.

      Because the signature lifetime is 10 days
      (in this example), the replayed signature and keyset is accepted
      as valid (being only 6 days old) and the RFC5011 Validator cancels
      the hold-down timer for K_new.

MGLT:
   T + 9: Replayed signature at published at T - 1 are not valid any more
and cannot be replayed. I believe T + 9 replaces T + 10.

   T+10  The RFC5011 Validator queries for the zone's keyset and
      discovers K_new again, signed by K_old (the attacker is unable to
      replay the records cached at T-1, because they have now expired).
      The RFC5011 Validator starts (anew) the hold-timer for K_new.

MGLT: I think we should explicitly specify that for 30 days, K_new will not
be used to validate. I also think it is important to note that the
validator can receive any response with Expiration Time greater then T + 9
and Inception Time lower than T + 9. This means that when dynamic
parameters are applied, we cannot assume that the response corresponds to
the values provided at T + 9.

   T+15,T+20, and T+25  The RFC5011 Validator continues checking the
      zone's key set and lets the hold-down timer keep running without
      resetting it.

   T+30  The Zone Signer knows that this is the first time at which some
      validators might accept K_new as a new trust anchor, since the
      hold-down timer of a RFC5011 Validator not under attack that had
      queried and retrieved K_new at T+0 would now have reached 30 days.
      However, the hold-down timer of our attacked RFC5011 Validator is
      only at 20 days.

   T+35  The Zone Signer (mistakenly) believes that all validators
      following the Active Refresh schedule (Section 2.3 of RFC5011)
      should have accepted K_new as a the new trust anchor (since the

Hardaker & Kumari        Expires October 5, 2017                [Page 5]

Internet-Draft       RFC5011 Security Considerations          April 2017

      hold down time of 30 days + 1/2 the signature validity period
      would have passed).
MGLT: There is a strong assumption that Expiration time is always set to
Zone generation + 10 days.

      However, the hold-down timer of our attacked
      RFC5011 Validator is only at 25 days; The replay attack at T+5
      means its new hold-time timer actually started at T+10, and thus
      at this time it's real hold-down timer is at T+35 - T+10 = 25
      days, which is less than the RFC5011 required 30 days.

   T+36  The Zone Signer, believing K_new is safe to use, switches their
      active signing KSK to K_new and publishes a new DNSKEY set
      signature signed with K_new.  Non-attacked RFC5011 validators,
      with a hold-down timer of at least 30 days, would have accepted
      K_new into their set of trusted keys.  But, because our attacked
      RFC5011 Validator still has a hold-down timer for K_new at 26
      days, it will fail to accept K_new as a trust anchor and since
      K_old is no longer being used, all the KSK records from the zone
      signed by K_new will be treated as invalid.  Subsequently, all
      keys in the key set are now unusable, invalidating all records in
      the zone of any type and name.

6.  Minimum RFC5011 Timing Requirements

   Given the attack description in Section 5, the correct minimum length
   of time required for the Zone Signer to wait before using K_new is:

MGLT:

On Thu, Apr 6, 2017 at 6:34 PM, Wes Hardaker <[email-masked]> wrote:

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