Re: [DNSOP] SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1

[Viktor Dukhovni <[e-mail]>]

On Tue, Jan 07, 2020 at 11:18:08AM -0500, Viktor Dukhovni wrote:

> This does not mean that staying with algorithm 7 (RSASHA1) is a good
> idea, but may buy more time to migrate in an orderly manner.

A thread today on dns-operations seems to suggest there's some confusion
about which uses of SHA-1 are at near-term risk of compromise, and which
still are still safe.

Executive summary:

    Zones signed with algorithms 5 and 7 SHOULD migrate to algorithms 8
    or (IMHO preferably) 13.  Especially when importing customer data or
    delegating child zones not under your control.

    Perhaps a draft is warranted that strengthens the advice to avoid 5
    and 7 in https://tools.ietf.org/html/rfc8624#section-3.1

Maybe I can shed some light on this, and make some recommendations.

    - There are still no known pre-image or 2nd pre-image attacks on
      SHA-1 where given a digest an attacker could create a different
      message with the same digest.

          Users of SHA-1 in a protocol that requires only pre-image
          resistance should still migrate to a stronger hash function
          (e.g.  SHA2-256), but they're not immediately at risk.

          For example, the use of SHA-1 as a digest type in DS records
          is not presently at risk, this only requires 2nd pre-image
          resistance.  Also the use of SHA-1 in NSEC3 records poses no
          new risk.

    - There are still no known attacks on SHA1-HMAC, indeed even
      HMAC-MD5 (IIRC) remains unbroken.  But neither are recommended
      in new applications.

          Users of SHA-1 in a protocol that employs a strong secret key
          with HMAC for data integrity should still migrate to a stronger
          secret MAC function (e.g.  HMAC-SHA2-256), but they're not
          immediately at risk.

    - Collision attacks, indeed "chosen-prefix" collision attacks on
      SHA-1 are now somewhat practical (at around 2^64 CPU cost).

          This substantially weakens SHA-1 when used for signing hashed
          content, where a long-enough portion of the content
          (especially the tail) is contributed by an outside party.

          The weakness is particularly significant when signatures are
          over "data at rest" (certificates, DS records, ...) rather
          than say TLS handshake messages, where the attack would have
          to be performed in real-time.

          Users of SHA-1 signatures over data that is not entirely
          *controlled by the signer*, should promptly begin moving to
          new signature algorithms that use SHA2-256 or similar.

In the context of DNSSEC what this might mean:

    - TLD and other public suffix zones that sign DS RRsets for
      child zones they don't control should phase out use of
      algorithms 5 and 7.  In the meantime DS record RDATA
      should be validated to have the expected hash value length.

    - Zones that consolidate and sign DNS records for multiple
      customers, without delegating a separate zone for each customer
      are at greater risk, as e.g. the longer free-form RDATA of
      TXT records makes a more attractive target for chosen-prefix
      attacks than DS record hashes.

    - Zones that only sign *their own* data, with no input from
      untrusted outsiders are not immediately at risk from the
      recent attacks, but should nevertheless plan to move away
      from algorithms 5 and 7 (to 8 or 13).

    - Perhaps a SHOULD NOT rather than NOT RECOMMENDED for DNSSEC
      Signing, while for now DNSSEC Validation continues to require
      support for 5 and 7, which are still common:

          https://stats.dnssec-tools.org/#parameter

      even among TLDs[1], with e.g. .ORG signed with algorithm 5.

-- 
    Viktor.

[1]

  -  274 TLDs sign with SHA-1 based signature algorithms 5 or 7
  - 1102 TLDs sign with SHA2 based signature algorithms 8, 10 or 13
  -    1 TLD  (.bg Bulgaria) is "mixed", it has both
              algorithms 5 and 8 in its DNSKEY RRset.