Paul Wouters wrote: > On Mon, 17 Mar 2014, Viktor Dukhovni wrote: >> >> This is not "use strongest". This is the opposite. It forces the >> use of tarnished, but still acceptable digests even when untarnished >> digests are present. The new proposal is to ignore all but the >> strongest, even when the remainder would be usable. >> >> Also the pseudo-code in the appendices loops over *all* "usable" TLSA >> RRs (those not banned by 4.1). > > Okay, I understand your point now. The text in 6698 is indeed doing some > half weird local policy client dictation that it should not have done.
DANE does not have any "tarnished" hash algorithms. DANE does not allow SHA1 at all and needs SHA-256 as a minimum. The weakest "link" is therefore the hash that is used by DNSSEC for the digital signature of the RRSET, which currently is SHA-1. As long as DNSSEC does not require "stronger than SHA-256", it will be pure bike-shedding to prefer a SHA-512 TLSA record over a SHA-256 one. And you probably do not want to hold your breath until DNSSEC has overcome SHA-1 based signatures. The notion that hashes allowed by DANE can be ordered by strength/weakness is also wrong. In the future, hashes with the same output size might get a codepoint assigned and used, and some of them might not be implemented by all DANE clients. Think of hashes from the russian GOST family of algorithms. Usage of SHA-512/256 over SHA-256 is not motivated by algorithm strength concerns, but rather by raw hash throughput considerations on 64-bit platforms. -Martin _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
