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. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop