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

Daniel Migault <daniel.migault@ericsson.com> Thu, 13 April 2017 17:54 UTC

Return-Path: <mglt.ietf@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89E813146D for <dnsop@ietfa.amsl.com>; Thu, 13 Apr 2017 10:54:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level:
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nO1smaNP0j2 for <dnsop@ietfa.amsl.com>; Thu, 13 Apr 2017 10:54:16 -0700 (PDT)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B04212EB09 for <dnsop@ietf.org>; Thu, 13 Apr 2017 10:54:06 -0700 (PDT)
Received: by mail-lf0-x22c.google.com with SMTP id t144so33316199lff.1 for <dnsop@ietf.org>; Thu, 13 Apr 2017 10:54:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=E/GqmkYFWure3mHrRXmIt1AadClFrE/eTkuboeET/Ck=; b=tx4Z3p/rJMsh7s8Q0TAhB+3zkWYaDp21Jn97DwOfjoW9dEq6rewgkUVp2TRI+9eUPz Dps/V0f6ozCUTn6g2EXLakCQODrj04HFMZ81cXJBSGyLEnx4Rp+KOzG+ETkYEV1Nf53h uW0u9ptPHL7GfjRIOWcqo10gb4QvXa7pTS0O6fmaehn0Jcu1yAkudELmcVNYixsTJ0Bp gTkv5yDeWiy9jazvcQr8b4C1W4TUVYHuA6ddOqFfENVgkYocuZqYUeq4tXyQcNJt5aXF 4HIL0uhkn5fuyho9fC2ddxDKTk1FDUzH5TlcPAC9O/xMrAe1ZmJuaaMlmBOBxRW1pIQL MbuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=E/GqmkYFWure3mHrRXmIt1AadClFrE/eTkuboeET/Ck=; b=XUO6oesENH/xbA21c/eOuT0mosRJY9svwJivnlQcI/OEY6w6PP/iOJsc3AQffyr2oY Mg+kuY1JURLGQzcB68zMmVdfqISNJpYCgetK4mZGbAdDjGsmOfr6UHio26+Xs4FSA6P1 4zEmH5++aL/YI3uwE3F8N4OvB0nW5a7fdXLPlwc/gu2hNeEh2NtsHenSCmrgXLiD3J8n Vr0jofORF7bMb5Ky4bQodtMplxoQk0eCOm2PRh6ETh1BLhfLMM1cV0aEoD780HsYCNXD LiIoTdaUfmhjabkuIQfhKYfQcpXbJvLvRmjkFF8sVY3EtiOj6v1f86oqLWwCSqKGCr0T OybA==
X-Gm-Message-State: AN3rC/5wTYDYnuiye+cWeUwSpjpnDM1LpiLR1RZBqnGyqZxq7jUG9Zpo qL+rDX0RvsIq6lJ+2dsNy6yjoUjt5A==
X-Received: by 10.25.155.145 with SMTP id d139mr1474309lfe.174.1492106044129; Thu, 13 Apr 2017 10:54:04 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.46.69.85 with HTTP; Thu, 13 Apr 2017 10:54:03 -0700 (PDT)
In-Reply-To: <yblpogpdv22.fsf@wu.hardakers.net>
References: <149130746853.30870.8028044269482471265@ietfa.amsl.com> <CA+nkc8BeT=4PKyi-ZH3NXTvZZdDkrSuBqjcAJYCG1aFmv4FPdQ@mail.gmail.com> <yblpogpdv22.fsf@wu.hardakers.net>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Thu, 13 Apr 2017 13:54:03 -0400
X-Google-Sender-Auth: IX_UBV3ypVPYBnsfbkm7zHzsowk
Message-ID: <CADZyTkmt0Ke1ZVQR8kZfFMzSe2qWB_UQasX1rSREaeLjBw=HjA@mail.gmail.com>
To: Wes Hardaker <wjhns1@hardakers.net>
Cc: Bob Harold <rharolde@umich.edu>, IETF DNSOP WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary=001a11402298ba47ae054d10021e
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/SnUvNfFT9-GxpSpQ4176yF_qriI>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Apr 2017 17:54:20 -0000

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 <wjhns1@hardakers.net> wrote:

> Bob Harold <rharolde@umich.edu> writes:
>
> > 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
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>