Internet DRAFT - draft-fanf-dnsop-sha-ll-not

draft-fanf-dnsop-sha-ll-not







DNS Operations                                                  T. Finch
Internet-Draft                                   University of Cambridge
Updates: 8624 (if approved)                                March 9, 2020
Intended status: Standards Track
Expires: September 10, 2020


    Hardening DNSSEC against collision weaknesses in SHA-1 and other
                     cryptographic hash algorithms
                     draft-fanf-dnsop-sha-ll-not-00

Abstract

   DNSSEC deployments have often used the SHA-1 cryptographic hash
   algorithm to provide authentication of DNS data.  This document
   explains why SHA-1 is no longer secure for this purpose, and
   deprecates its use in DNSSEC signatures.  This document updates RFC
   8624.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 10, 2020.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Finch                  Expires September 10, 2020               [Page 1]

Internet-Draft         DNSSEC vs collision attacks            March 2020


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Deprecating SHA-1 in DNSSEC . . . . . . . . . . . . . . . . .   3
     2.1.  DNSSEC signing software . . . . . . . . . . . . . . . . .   4
     2.2.  DNS hosting services  . . . . . . . . . . . . . . . . . .   4
     2.3.  DNSSEC validating software  . . . . . . . . . . . . . . .   4
     2.4.  DNS resolver services . . . . . . . . . . . . . . . . . .   5
   3.  Collision attacks against DNSSEC  . . . . . . . . . . . . . .   5
     3.1.  Chosen-prefix collisions  . . . . . . . . . . . . . . . .   5
     3.2.  Collision attacks and signatures  . . . . . . . . . . . .   5
     3.3.  Breaking DNSSEC . . . . . . . . . . . . . . . . . . . . .   6
     3.4.  Collision attacks and RRSIG records . . . . . . . . . . .   6
   4.  Hardening RRSIG records . . . . . . . . . . . . . . . . . . .   7
     4.1.  Predicting inception and expiration times . . . . . . . .   8
     4.2.  Unpredictable X.509 certificates  . . . . . . . . . . . .   8
     4.3.  Less predictable RRSIG records  . . . . . . . . . . . . .   9
   5.  Collision attacks and other DNS record types  . . . . . . . .   9
     5.1.  TXT records . . . . . . . . . . . . . . . . . . . . . . .   9
       5.1.1.  Syntax of TXT records . . . . . . . . . . . . . . . .  10
       5.1.2.  Mitigating TXT record attacks . . . . . . . . . . . .  10
     5.2.  CAA records . . . . . . . . . . . . . . . . . . . . . . .  10
     5.3.  SSHFP records . . . . . . . . . . . . . . . . . . . . . .  11
     5.4.  DNSKEY records  . . . . . . . . . . . . . . . . . . . . .  11
       5.4.1.  Shared keys . . . . . . . . . . . . . . . . . . . . .  11
       5.4.2.  Combined signing keys . . . . . . . . . . . . . . . .  11
     5.5.  DS records  . . . . . . . . . . . . . . . . . . . . . . .  12
   6.  Other uses of SHA-1 in the DNS  . . . . . . . . . . . . . . .  12
     6.1.  DS and CDS records  . . . . . . . . . . . . . . . . . . .  12
     6.2.  NSEC3 records . . . . . . . . . . . . . . . . . . . . . .  13
     6.3.  SSHFP records . . . . . . . . . . . . . . . . . . . . . .  13
     6.4.  TSIG authentication . . . . . . . . . . . . . . . . . . .  13
   7.  Security considerations . . . . . . . . . . . . . . . . . . .  13
     7.1.  Staying secure  . . . . . . . . . . . . . . . . . . . . .  14
     7.2.  When to declare SHA-1 insecure  . . . . . . . . . . . . .  14
     7.3.  Avoiding unwanted insecurity  . . . . . . . . . . . . . .  14
   8.  IANA considerations . . . . . . . . . . . . . . . . . . . . .  14
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  18
   Appendix B.  Timeline . . . . . . . . . . . . . . . . . . . . . .  18
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  18




Finch                  Expires September 10, 2020               [Page 2]

Internet-Draft         DNSSEC vs collision attacks            March 2020


1.  Introduction

   Since 2005, SHA-1 has been known to be much weaker than it was
   designed to be.  Over the last 5 years there has been a series of
   increasingly powerful demonstrations that SHA-1's weaknesses can be
   exploited in practice.  In January 2020, Gaetan Leurent and Thomas
   Peyrin announced a chosen-prefix collision for SHA-1 [SHA-mbles].
   This was the first practical break of SHA-1 as used in cryptographic
   signatures.

   DNSSEC uses cryptographic signatures to authenticate DNS data.  Its
   signature algorithms [DNSKEY-IANA] include RSASHA1 (5) and
   RSASHA1-NSEC3-SHA1 (7) which are vulnerable to chosen-prefix
   collisions in SHA-1, as described in Section 3.  This document
   deprecates these vulnerable algorithms (Section 2).

   SHA-1 has been deprecated in other situations for several years (see
   Appendix B).  This document's timetable for deprecating SHA-1 in
   DNSSEC (Section 2) is based on those examples, adapted for the
   particulars of the DNS.  Section 7 discusses the trade-offs between
   speedy deprecation and security.

   A collision attack can be used against DNSSEC in a number of ways,
   some of which are explored in Section 5.  Certain weaknesses in the
   way DNSSEC is sometimes deployed can make collision attacks easier to
   carry out, or make their consequences more severe.  Although the only
   sure way to protect against collision attacks is to use a secure
   algorithm (Section 2), Section 4 and Section 5 outline some partial
   mitigations.

   The DNS uses SHA-1 for a number of other less vulnerable purposes, as
   outlined in section Section 6.

1.1.  Terminology

   The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be
   interpreted as described in [RFC2119].

2.  Deprecating SHA-1 in DNSSEC

   The following table lists the implementation recommendations for
   DNSKEY algorithms [DNSKEY-IANA].  The change from [RFC8624] section
   3.1 is to deprecate algorithms 5 and 7.







Finch                  Expires September 10, 2020               [Page 3]

Internet-Draft         DNSSEC vs collision attacks            March 2020


   +-----+--------------------+-----------------+---------------------+
   | No. | Mnemonic           | DNSSEC Signing  | DNSSEC Validation   |
   +-----+--------------------+-----------------+---------------------+
   | 1   | RSAMD5             | MUST NOT        | MUST NOT            |
   | 3   | DSA                | MUST NOT        | MUST NOT            |
   | 5   | RSASHA1            | MUST NOT        | MUST NOT after 2021 |
   | 6   | DSA-NSEC3-SHA1     | MUST NOT        | MUST NOT            |
   | 7   | RSASHA1-NSEC3-SHA1 | MUST NOT        | MUST NOT after 2021 |
   | 8   | RSASHA256          | MUST            | MUST                |
   | 10  | RSASHA512          | NOT RECOMMENDED | MUST                |
   | 12  | ECC-GOST           | MUST NOT        | MAY                 |
   | 13  | ECDSAP256SHA256    | MUST            | MUST                |
   | 14  | ECDSAP384SHA384    | MAY             | RECOMMENDED         |
   | 15  | ED25519            | RECOMMENDED     | RECOMMENDED         |
   | 16  | ED448              | MAY             | RECOMMENDED         |
   +-----+--------------------+-----------------+---------------------+

   The following subsections have recommended timelines for deprecating
   algorithms 5 and 7 in specific situations.

2.1.  DNSSEC signing software

   DNSSEC key management and zone signing software MUST remove support
   for algorithms 5 and 7 in their next feature release.

2.2.  DNS hosting services

   Authoritative DNS hosting services that include DNSSEC signing as
   part of the service SHOULD NOT generate a new key with algorithms 5
   or 7 for a zone that does not already have a key with the same
   algorithm.  They MUST NOT do so after the end of 2020.

   Zones signed with algorithms 5 or 7 SHOULD be rolled over to a
   mandatory algorithm (13 or 8) as soon as possible.  The rollovers
   MUST be complete before the end of 2021.

2.3.  DNSSEC validating software

   Validating resolvers SHOULD have a build-time or run-time option to
   disable selected DNSKEY algorithms, that is, to treat them as unknown
   or insecure.

   Algorithms 5 and 7 MUST be disabled in 2022 at the latest.  If SHA-1
   becomes significantly weaker before then, Algorithms 5 and 7 MUST be
   disabled in a security patch release.






Finch                  Expires September 10, 2020               [Page 4]

Internet-Draft         DNSSEC vs collision attacks            March 2020


2.4.  DNS resolver services

   Validating resolvers MUST treat algorithms 5 and 7 as unknown or
   insecure after the start of 2022, or earlier if SHA-1 becomes
   significantly weaker before then.

3.  Collision attacks against DNSSEC

   This section explains how collisions in cryptographic functions (such
   as SHA-1) can be used to break DNSSEC data authentication.  Section 5
   has some more specific examples of how this break can be used to
   mount attacks.

3.1.  Chosen-prefix collisions

   With hash functions like SHA-1, a chosen-prefix collision attack uses
   two messages that have a structure like this:

               +----------+-----------+--------+
   message-1:  | prefix-1 | collide-1 | suffix |
               +----------+-----------+--------+

               +----------+-----------+--------+
   message-2:  | prefix-2 | collide-2 | suffix |
               +----------+-----------+--------+

   The two prefixes are entirely under the attacker's control.

   The collision blocks are calculated to make the hashes collide.  They
   look like binary junk and cannot be made to conform to any particular
   syntax.  The collision blocks are 588 bytes long in the best attack
   on SHA-1 at the time of writing [SHA-mbles].

   The messages may need a suffix so that they are syntactically valid,
   but this must be the same in both messages.

3.2.  Collision attacks and signatures

   A signature algorithm like RSASHA1 takes a cryptographic hash of the
   message (using SHA-1 in this case) and uses an asymmetric algorithm
   (RSA in this case) to turn the hash into a signature.

   If the hash function is vulnerable, like SHA-1, then an attacker can:

   o  construct two prefixes, one innocuous and one malicious;

   o  calculate collision blocks so the two messages have the same hash;




Finch                  Expires September 10, 2020               [Page 5]

Internet-Draft         DNSSEC vs collision attacks            March 2020


   o  submit the innocuous message to be signed by some authority;

   o  copy the signature from the innocious message to the malicious
      message;

   o  use the signed malicious message to perform attacks that would not
      be possible without it.

   The copied signature works on both the innocuous and malicious
   messages because their hashes match.

   It is usually less easy than this, because in most protocols part of
   the innocuous message is chosen by the signer, so the attacker needs
   to predict how the signer will work.

3.3.  Breaking DNSSEC

   To use a collision attack against DNSSEC, the innoccuous and
   malicious messages are DNS RRsets.

   DNSSEC provides strong authentication for DNS data.  Within the DNS,
   it prevents spoofing attacks and cache poisoning attacks.  For
   applications that use the DNS, DNSSEC can provide strong
   authentication for application identifiers, such as a host name and
   associated public key or challenge/response.  Breaking DNSSEC means
   subverting this authentication.

   If an attacker has even very limited access to update a DNS zone that
   uses SHA-1 (algorithm 5 or 7), the attacker can use a collision
   attack to gain control over other names in the same zone.

   Our attacker is able to update the DNS for certain innoccuous
   records.  The zone owner signs the updated innoccuous records and
   publishes the new records and RRSIG in the zone.  The attacker can
   then make a DNS query for the updated records, and copy the signature
   field from the innoccuous RRSIG into the signature field of the
   attacker's malicious RRSIG.  The attacker can use the signed
   malicious RRset as part of a DNS spoofing or cache poisoning attack.
   Section 5 has some examples.

3.4.  Collision attacks and RRSIG records

   When the attacker calculates the collision blocks, there is a bit
   more to the innoccuous and malicious messages than just the RRsets.
   They need to be in the format used for constructing RRSIG records
   specified in [RFC4034] section 3.1.8.1 and sketched in the diagram
   below:




Finch                  Expires September 10, 2020               [Page 6]

Internet-Draft         DNSSEC vs collision attacks            March 2020


   +------------------------------------+
   | RRSIG RDATA                        |
   +------------------------------------+
   | NAME TYPE CLASS TTL RDLENGTH RDATA |
   +------------------------------------+
   | ... more records ...               |
   +------------------------------------+
   | NAME TYPE CLASS TTL RDLENGTH (     |
   |                 collision blocks ) |
   +------------------------------------+

   The RRSIG RDATA is controlled by the signer, and must be predicted by
   the attacker.  Section 4 discusses how easy it is to predict the
   RRSIG RDATA fields.

   The DNS records are under the attacker's control, with some
   limitations:

   o  In the innoccuous records, the NAME and TYPE identify an RRset
      that the attacker can update.

   o  In the malicious records, the NAME must be in a zone signed by the
      same key as the innoccuous records.

   o  The innoccuous and malicious TYPEs do not need to be the same, but
      they must both have RDATA fields that can accommodate the
      collision blocks.

   o  The attacker needs to ensure the records containg the collision
      blocks come last when the RRsets are sorted into canonical order.

   o  The innoccuous and malicious records do not have to be aligned
      with each other, but they need to have the same total length.

4.  Hardening RRSIG records

   To perform a collision attack against DNSSEC, the attacker needs to
   know the RRSIG RDATA fields that the zone owner will use when signing
   the attacker's innoccuous records.

   The RRSIG RDATA fields are specified in [RFC4034] section 3.1.  They
   are:

   o  Type covered: same as the TYPE of the innoccuous RRset.

   o  Algorithm: same as the algorithm of the zone's DNSKEY records,
      which for a vulnerable zone will be 5 or 7.




Finch                  Expires September 10, 2020               [Page 7]

Internet-Draft         DNSSEC vs collision attacks            March 2020


   o  Labels: derived from the NAME of the innoccuous RRset.

   o  Original TTL: same as the TTL of the innoccuous RRset.

   o  Signature expiration: a time set by the signer.

   o  Signature inception: a time set by the signer.

   o  Key tag: obtained from one of the zone's DNSKEY records.

   o  Signer's name: the name of the zone's DNSKEY records.

   We can see that all of these fields are known to the attacker, apart
   from the inception and expiration times.

4.1.  Predicting inception and expiration times

   There are a number of common ways for DNSSEC signers to set signature
   inception and expiration times:

   o  The times are known offsets from the moment a DNS update is
      processed.

   o  The update time is rounded to a multiple of (for example) 24 hours
      and the signature times are known offsets from that.

   o  The zone is signed on a known schedule and the times are derived
      from that schedule.

   So in many cases an attacker can predict all the RRSIG RDATA fields
   with little difficulty.

4.2.  Unpredictable X.509 certificates

   (A brief diversion to provide some rationale for the next sub-
   section.)

   In 2008 a chosen-prefix collision attack against MD5 was used to
   obtain an illegitimate CA certificate signed by a commercial CA
   [ROGUE-CA].  A key part of this attack was to predict the serial
   number and validity period assigned by the commercial CA to the
   innocuous certificate so that its MD5 hash would collide with the
   malicious rogue CA certificate.

   Following this attack, certificate authorities started using random
   serial numbers instead of sequential numbers.  In 2016 the CA/Browser
   forum baseline requirements were amended to increase the amount of




Finch                  Expires September 10, 2020               [Page 8]

Internet-Draft         DNSSEC vs collision attacks            March 2020


   randomness required from 20 bits to 64 bits [CABforum2016].  This
   extra hardening was in addition to deprecating SHA-1 [CABforum2014].

4.3.  Less predictable RRSIG records

   In addition to upgrading to a secure algorithm (Section 2), DNSSEC
   signers can provide extra protection against possible collision
   attacks by adding entropy to make RRSIG inception and expiration
   times less predictable.

   The inception time SHOULD include at least 12 bits of output from a
   CSPRNG. (2^12 seconds is slightly more than an hour.)  For example,
   set the inception time to the signing time minus an hour minus the
   entropy.

   The expiration time SHOULD include output from a CSPRNG equivalent to
   about 25% of the nominal validity period.  For instance, 19 bits (6
   days) if the validity period is 1 month, or 17 bits (1.5 days) if the
   validity period is 1 week.  For example, set the expiration time to
   the signing time plus 75% of the validity period plus the entropy.

   A signer SHOULD change its signature validity times frequently, for
   example, different times for each RRset, or different times each
   second.  This is so that an attacker cannot observe the signer's
   current validity period and perform a collision attack before the
   period changes.

5.  Collision attacks and other DNS record types

   This section discusses how a SHA-1 collision attack can be used with
   various DNS record types.  For an RRtype to be suitable it needs to
   have a large RDATA with basically no internal structure, to
   accommodate the collision blocks, which are 588 bytes long in the
   best attack on SHA-1 at the time of writing [SHA-mbles].

   There are a number of weaknesses that make a collision attack easier
   to carry out, or which make the consequences of an attack more
   severe.  This section describes some mitigations for these
   weaknesses, but note that these mitigations do not prevent collision
   attacks.  The main defence is to upgrade zones to a secure algorithm
   (Section 2) and in many cases that will be easier than the additional
   mitigations outlined below.

5.1.  TXT records

   TXT records are an attractive vehicle for a collision attack.





Finch                  Expires September 10, 2020               [Page 9]

Internet-Draft         DNSSEC vs collision attacks            March 2020


   Access to update TXT records might be granted to support things like
   ACME dns-01 challenges [RFC8555], so they can be useful as an
   attacker's innoccuous records.

   As the target of an attacker's malicious records, TXT records have
   several interesting functions that might be useful to an attacker,
   including ACME [RFC8555], DKIM [RFC6376], SPF [RFC7208],
   authorization to provision cloud services, etc.

5.1.1.  Syntax of TXT records

   A TXT record's RDATA contains a sequence of strings, each of which is
   a length octet followed by up to 255 octets of data.  A single string
   is too small to accommodate SHA-1 collision blocks.

   An attacker can cope with this difficulty by not worrying about how
   the string lengths end up inside a collision block.  At the end of
   the block there will be some unpredictable length of string that
   needs to be filled; the attacker can append 255 zero bytes, which
   will fill the remainder of the unknown string.  The excess zero bytes
   will parse as a sequence of zero-length strings.  Although the
   unfilled string lengths may be different in the inoccuous and
   malicious records, they are both fixed by an identical suffix of 255
   zeroes.

5.1.2.  Mitigating TXT record attacks

   Some attacks might be prevented by imposing stricter requirements on
   TXT records, since most practical uses do not put un-encoded binary
   data in TXT records.

   An authoritative server MAY reject TXT records in DNS UPDATEs and
   zone files if the strings contain ASCII control characters or invalid
   UTF-8.  This strict checking SHOULD be configurable so that zone
   owners can use unrestricted binary in TXT records if they wish.

5.2.  CAA records

   An attacker might want to spoof certificate authority authorization
   records [RFC8659] in order to obtain an illegitimate X.509
   certificate.

   A CAA record contains tag and value strings.  The length of the value
   is unrestricted, which makes it easy to accommodate collision blocks.

   To mitigate collision attacks on CAA records, the specifications for
   CAA record syntax and how CAA records are processed by certificate




Finch                  Expires September 10, 2020              [Page 10]

Internet-Draft         DNSSEC vs collision attacks            March 2020


   authorities could be tightened up to reject a CAA RRset unless it is
   all printable ASCII.

5.3.  SSHFP records

   An SSHFP record contains a fingerprint of a server public key
   [RFC4255].  They are attractive as the target of a spoofing attack.

   Access to update SSHFP records might be granted so that servers can
   register themselves in the DNS, so SSHFP records can be useful as an
   attacker's innoccuous records.

   The length of an SSHFP record is implied by its fingerprint type
   field, but they can be used in collision attacks if the length is not
   strictly checked, or if unknown fingerprint types are allowed.

   Authoritative DNS servers MAY reject SSHFP records with unknown
   fingerprint types or mismatched lengths in DNS UPDATEs and zone
   files.  SSH clients MAY reject an entire SSHFP RRset if any record
   has a fingerprint longer than 64 bytes.  (Assuming that fingerprints
   longer than 512 bits do not make sense.)

5.4.  DNSKEY records

   There are a couple of DNSSEC key management models that can make the
   consequences of a collision attack worse.

5.4.1.  Shared keys

   Normally each zone has its own DNSSEC keys, so a collision attack
   only works when the attacker's inoccuous and malicious records are in
   the same zone.

   Some DNSSEC deployments share the same keys across multiple zones.
   This allows an attacker to target names in any zone that uses the
   same key.  For example, if this is a multi-tenant hosting
   environment, the attacker could sign up with their own domain and use
   that to perform collision attacks against other customers on the same
   platform.

   DNS hosting services and DNSSEC signing software SHOULD NOT allow
   keys to be shared between multiple zones.

5.4.2.  Combined signing keys

   The traditional DNSSEC setup has two keys for a zone: a key-signing
   key (KSK) that is only used to sign the zone's DNSKEY RRset; and a
   zone-signing key (ZSK) which signs the other records in the zone.



Finch                  Expires September 10, 2020              [Page 11]

Internet-Draft         DNSSEC vs collision attacks            March 2020


   There is a simpler setup in which a zone has only one key: a combined
   signing key (CSK) which signs all the records in the zone.

   The DNSKEY RRset is a huge target in a zone that is vulnerable to
   collision attacks: if the attacker can get their own public key into
   a signed DNSKEY RRset then one successful collision attack can be
   used to spoof any record in the zone.

   In a zone with split ZSK/KSK, the DNSKEY RRset is only trusted if it
   is signed by the KSK, but collision attacks can only obtain a RRset
   signed by the ZSK.

   In a zone with a CSK the attacker can obtain a malicious trusted
   DNSKEY RRset using a collision attack.

   DNS hosting services and DNSSEC signing software SHOULD encourage
   split ZSK/KSK configurations.

5.5.  DS records

   Top-level domains are the most prominent example of zones that can be
   updated by many different clients from mutually antagonistic
   organizations.

   TLDs are typically updated via EPP [RFC5730].  The only delegation
   RRtype it might be possible to use for collision attacks are DS
   records.  (The other delegation records, NS and glue addresses, are
   not signed and their syntax is too constrained.)

   Collision attacks using DS records SHOULD be prevented as follows:

   o  Unknown DS digest types are rejected;

   o  DS records are required to have the correct length for their
      digest type;

   o  Alternatively, instead of using client-generated DS records, the
      registry accepts DNSKEY records and generates the DS records.

6.  Other uses of SHA-1 in the DNS

6.1.  DS and CDS records

   A DS or CDS record securely identifies a DNSKEY record using a
   cryptographic digest ([RFC4034] section 5).  One of the digest types
   is SHA-1.  It is deprecated by [RFC8624].





Finch                  Expires September 10, 2020              [Page 12]

Internet-Draft         DNSSEC vs collision attacks            March 2020


   For this purpose, the digest needs preimage security, which SHA-1
   still has, and collision attacks do not affect it.

6.2.  NSEC3 records

   NSEC3 is an alternative mechanism for authenticated denial of
   existence in DNSSEC.  It is based on SHA-1 hashes of domain names.
   The NSEC3 specification [RFC5155] discusses collisions in some
   detail.

   NSEC3 can be attacked with an identical-prefix collision, which is
   simpler than the chosen-prefix collisions that are the main subject
   of this document.  The best collision known at the time of writing
   [SHAttered] uses two SHA-1 input blocks (128 bytes) so a collision
   could in principle be made to fit into a domain name for an attack on
   NSEC3.  However it will be difficult to make the colliding domain
   names conform to host name syntax, and the attack will be futile
   because the signer can defeat it by changing its NSEC3 salt
   ([RFC5155] section C.2.1).

6.3.  SSHFP records

   An SSHFP record securely identifies an SSH server public key using a
   cryptographic digest [RFC4255].  Although SSHFP SHA-1 digests have
   not yet been deprecated, SHA-256 is preferred [RFC6594].

   For SSHFP records the digest needs preimage security, which SHA-1
   still has, and collision attacks do not affect it.

6.4.  TSIG authentication

   TSIG is a DNS extension for secret-key transaction authentication
   [I-D.ietf-dnsop-rfc2845bis].  Its "hmac-sha1" algorithm is
   deprecated.  Collision attacks do not affect HMAC SHA-1.

7.  Security considerations

   We find ourselves in an awkward and embarrassing situation.  As
   Appendix B shows, there has been plenty of warning about the weakness
   of SHA-1.  Other parts of the industry started making efforts to
   deprecate it years ago.  But DNSSEC has been complacent.

   At the time of writing, there are 1516 top-level domains, of which
   1102 use secure DNSSEC algorithms, 274 use algorithms 5 or 7 (RSA
   SHA-1), and 140 are insecure.  In the reverse DNS, 3 RIRs use secure
   DNSSEC algorithms, 2 RIRs use algorithm 5, and many of the non-RIR
   legacy delegations are insecure.




Finch                  Expires September 10, 2020              [Page 13]

Internet-Draft         DNSSEC vs collision attacks            March 2020


7.1.  Staying secure

   There are still many domains that depend on SHA-1 to secure
   applications that use DNSSEC, such as issuing TLS certificates
   [RFC8659] [RFC8555], sending inter-domain email [RFC7672], and
   authenticating SSH servers [RFC4255].

   Some applications use the "authenticated data" (AD bit) signal from
   DNSSEC to make security decisions, and will fail if it unexpectedly
   switches off.  Other applications use DNSSEC passively and will
   silently go insecure.  In either case we would prefer them to
   continue working as if secure, as long as SHA-1 is still
   significantly better than insecure DNS.

7.2.  When to declare SHA-1 insecure

   At the time of writing, a SHA-1 chosen-prefix collision costs less
   than US$100,000 in computer time, takes about a month, and requires
   the attention of expert cryptanalysts.  Attacks seem to be getting
   better by a factor of 3 or 4 per year.

   There is not much time before collisions become affordable, and
   possible for non-experts to calculate.  Section 2 hopes this will not
   happen within the next 2 years.

   This 2 year guess is likely to be too optimistic, so DNSSEC
   validators need to be prepared to disable support for SHA-1 by
   configuration change or security patch as soon as a significantly
   improved attack on SHA-1 is announced.

7.3.  Avoiding unwanted insecurity

   The reason for not deprecating SHA-1 immediately is to allow time to
   perform algorithm rollovers, so that zones will continue to be
   secure.

   Abruptly forcing SHA-1 zones to be treated as insecure may encourage
   their operators to leave them insecure, instead of encouraging them
   to upgrade to a secure algorithm.

8.  IANA considerations

   This document has no IANA actions.








Finch                  Expires September 10, 2020              [Page 14]

Internet-Draft         DNSSEC vs collision attacks            March 2020


9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, DOI 10.17487/RFC4034, March 2005,
              <https://www.rfc-editor.org/info/rfc4034>.

   [RFC8624]  Wouters, P. and O. Sury, "Algorithm Implementation
              Requirements and Usage Guidance for DNSSEC", RFC 8624,
              DOI 10.17487/RFC8624, June 2019,
              <https://www.rfc-editor.org/info/rfc8624>.

9.2.  Informative References

   [CABforum2014]
              CA/Browser Forum, "Ballot 118 - SHA-1 Sunset", October
              2014, <https://cabforum.org/2014/10/16/ballot-118-sha-
              1-sunset/>.

   [CABforum2016]
              CA/Browser Forum, "Ballot 164 - Certificate Serial Number
              Entropy", September 2016,
              <https://cabforum.org/2016/03/31/ballot-164/>.

   [Cochran2007]
              Cochran, M., "Notes on the Wang et al. 2^63 SHA-1
              Differential Path", 2007,
              <https://eprint.iacr.org/2007/474>.

   [DNSKEY-IANA]
              IANA, "Domain Name System Security (DNSSEC) Algorithm
              Numbers", 2017,
              <http://www.iana.org/assignments/dns-sec-alg-numbers>.

   [I-D.ietf-dnsop-rfc2845bis]
              Dupont, F., Morris, S., Vixie, P., Eastlake, D.,
              Gudmundsson, O., and B. Wellington, "Secret Key
              Transaction Authentication for DNS (TSIG)", draft-ietf-
              dnsop-rfc2845bis-07 (work in progress), February 2020.





Finch                  Expires September 10, 2020              [Page 15]

Internet-Draft         DNSSEC vs collision attacks            March 2020


   [NIST-SP800-131A]
              National Institute of Standards and Technology,
              "Recommendation for Transitioning the Use of
              CryptographicAlgorithms and Key Lengths", January 2011,
              <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/
              nistspecialpublication800-131a.pdf>.

   [NIST2006]
              National Institute of Standards and Technology, "NIST
              Comments on Cryptanalytic Attacks on SHA-1", 2006,
              <https://csrc.nist.gov/News/2006/NIST-Comments-on-
              Cryptanalytic-Attacks-on-SHA-1>.

   [RFC4255]  Schlyter, J. and W. Griffin, "Using DNS to Securely
              Publish Secure Shell (SSH) Key Fingerprints", RFC 4255,
              DOI 10.17487/RFC4255, January 2006,
              <https://www.rfc-editor.org/info/rfc4255>.

   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
              Security (DNSSEC) Hashed Authenticated Denial of
              Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
              <https://www.rfc-editor.org/info/rfc5155>.

   [RFC5730]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
              STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
              <https://www.rfc-editor.org/info/rfc5730>.

   [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
              "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
              RFC 6376, DOI 10.17487/RFC6376, September 2011,
              <https://www.rfc-editor.org/info/rfc6376>.

   [RFC6594]  Sury, O., "Use of the SHA-256 Algorithm with RSA, Digital
              Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA)
              in SSHFP Resource Records", RFC 6594,
              DOI 10.17487/RFC6594, April 2012,
              <https://www.rfc-editor.org/info/rfc6594>.

   [RFC6944]  Rose, S., "Applicability Statement: DNS Security (DNSSEC)
              DNSKEY Algorithm Implementation Status", RFC 6944,
              DOI 10.17487/RFC6944, April 2013,
              <https://www.rfc-editor.org/info/rfc6944>.

   [RFC7208]  Kitterman, S., "Sender Policy Framework (SPF) for
              Authorizing Use of Domains in Email, Version 1", RFC 7208,
              DOI 10.17487/RFC7208, April 2014,
              <https://www.rfc-editor.org/info/rfc7208>.




Finch                  Expires September 10, 2020              [Page 16]

Internet-Draft         DNSSEC vs collision attacks            March 2020


   [RFC7672]  Dukhovni, V. and W. Hardaker, "SMTP Security via
              Opportunistic DNS-Based Authentication of Named Entities
              (DANE) Transport Layer Security (TLS)", RFC 7672,
              DOI 10.17487/RFC7672, October 2015,
              <https://www.rfc-editor.org/info/rfc7672>.

   [RFC8555]  Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
              Kasten, "Automatic Certificate Management Environment
              (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
              <https://www.rfc-editor.org/info/rfc8555>.

   [RFC8659]  Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews,
              "DNS Certification Authority Authorization (CAA) Resource
              Record", RFC 8659, DOI 10.17487/RFC8659, November 2019,
              <https://www.rfc-editor.org/info/rfc8659>.

   [ROGUE-CA]
              Sotirov, A., Stevens, M., Appelbaum, J., Lenstra, A.,
              Molnar, D., Osvik, D., and B. de Weger, "Creating a rogue
              CA certificate", December 2008,
              <https://www.win.tue.nl/hashclash/rogue-ca/>.

   [ROOT-DNSSEC]
              Internet Corporation For Assigned Names and Numbers and
              VeriSign, Inc., "Information about DNSSEC for the Root
              Zone", 2010, <https://www.root-dnssec.org/>.

   [SHA-mbles]
              Leurent, G. and T. Peyrin, "SHA-1 is a Shambles: First
              Chosen-Prefix Collision on SHA-1 and Application to the
              PGP Web of Trust", January 2020,
              <https://sha-mbles.github.io/>.

   [SHAppening]
              Stevens, M., Karpman, P., and T. Peyrin, "Freestart
              collision for full SHA-1", October 2015,
              <https://sites.google.com/site/itstheshappening/>.

   [SHAttered]
              Stevens, M., Bursztein, E., Karpman, P., Albertini, A.,
              and Y. Markov, "The first collision for full SHA-1",
              February 2017, <https://shattered.io/>.

   [Wang2005]
              Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the
              Full SHA-1", 2005,
              <https://link.springer.com/chapter/10.1007/11535218_2>.




Finch                  Expires September 10, 2020              [Page 17]

Internet-Draft         DNSSEC vs collision attacks            March 2020


Appendix A.  Acknowledgments

   Thanks to Viktor Dukhovni for helpful discussions about the
   implications of the SHA-1 chosen-prefix collision.

Appendix B.  Timeline

   o  2005: Theoretical 2^63 attack on SHA-1 [Wang2005] [Cochran2007]

   o  2006: NIST starts to deprecate SHA-1 [NIST2006]

   o  2010: DNS root zone signed with RSASHA256 [ROOT-DNSSEC]

   o  2011: NIST formally deprecates SHA-1 for digital signatures, and
      disallows it after 2013 [NIST-SP800-131A] (section 3)

   o  2013: IETF recommends RSASHA1 for use in DNSSEC [RFC6944]

   o  2014: CA/Browser forum sunsets SHA-1 in X.509 WebPKI certificates
      after 2015 [CABforum2014]

   o  2015: Free-start collision demonstrated in SHA-1 [SHAppening]

   o  2017: Identical-prefix collision demonstrated in SHA-1 [SHAttered]

   o  2019: IETF partially deprecates SHA-1 for use in DNSSEC [RFC8624]

   o  2020: Chosen-prefix collision demonstrated in SHA-1 [SHA-mbles]

Author's Address

   Tony Finch
   University of Cambridge
   University Information Services
   Roger Needham Building
   7 JJ Thomson Avenue
   Cambridge  CB3 0RB
   England

   Email: dot@dotat.at











Finch                  Expires September 10, 2020              [Page 18]