Hi Rob, One can do a bit of semi-generic analysis here to help motivate 12 bytes as being a tolerable choice (one could make some argument for 32 being the right length to actually use, but the protocol-mandated floor does not necessarilly need to be the "full protection" value as there can be trade-offs in play.
There's two general classes of attack to consider: when an external attacker takes an existing ZONEMD and tries to modify the associated zone, or when the zone provider is the malicious entity that wants to provide different content to different people but give them the same digest value so that the cursory examination indicates the two different zones are identical. (The second one is going to be fairly contrived most of the time, and may not be in the practical threat model for most people.) In the former case the cryptographic property in play is second-preimage resistance which, in the absence of a quantum computer, scales as the bitlength of the output, so 12 bytes of digest means that for a good hash function the attacker has to put in a work factor of roughly 2**96, which is a substantial burden. The cryptographic property in play for the second case is regular collision resistance, which scales as the square root of the preimage problem due to the birthday paradox. A work factor of 2**48 is feasible but nontrivial, so 12 bytes poses some burden for both classes of attack and a substantial burden for the riskier attack. To me, that seems like a reasonable tradeoff for the bare minimum allowed by the protocol, though of course opinions can differ. -Ben On Fri, Oct 09, 2020 at 11:10:14PM -0400, Donald Eastlake wrote: > Hi Rob, > > I'm not aware of any precise analysis supporting the 12 byte minimum > size but I believe it is reasonable and in line with the lower end of > the range of hash sizes typically standardized by the IETF these days. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e...@gmail.com > > On Fri, Oct 9, 2020 at 5:23 AM Rob Wilton (rwilton) <rwil...@cisco.com> wrote: > > > > Hi Donald, > > > > > -----Original Message----- > > > From: Donald Eastlake <d3e...@gmail.com> > > > Sent: 09 October 2020 00:47 > > > To: Rob Wilton (rwilton) <rwil...@cisco.com> > > > Cc: The IESG <i...@ietf.org>; draft-ietf-dnsop-dns-zone-dig...@ietf.org; > > > Tim Wicinski <tjw.i...@gmail.com>; <dnsop@ietf.org> <dnsop@ietf.org>; > > > dnsop-cha...@ietf.org > > > Subject: Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns- > > > zone-digest-12: (with COMMENT) > > > > > > On Thu, Oct 8, 2020 at 7:18 AM Robert Wilton via Datatracker > > > <nore...@ietf.org> wrote: > > > > Robert Wilton has entered the following ballot position for > > > > draft-ietf-dnsop-dns-zone-digest-12: No Objection > > > > > > > > ... > > > > > > > > ---------------------------------------------------------------------- > > > > COMMENT: > > > > ---------------------------------------------------------------------- > > > > > > > > ... > > > > > > > > 2.2.4. The Digest Field > > > > > > > > The Digest field MUST NOT be shorter than 12 octets. Digests for > > > the > > > > SHA384 and SHA512 hash algorithms specified herein are never > > > > truncated. Digests for future hash algorithms MAY be truncated, > > > but > > > > MUST NOT be truncated to a length that results in less than 96- > > > bits > > > > (12 octets) of equivalent strength. > > > > > > > > When I read this, I wonder why the limit of 12 bytes was chosen. > > > Possibly a > > > > sentence that justifies why this value was chosen might be useful, > > > noting that > > > > the two suggested algorithms have significantly longer digests. > > > > > > To me, the purpose of the limit is to establish a minimum strength > > > against brute force attacks. Of course, the hash algorithm also has to > > > be strong but the length of the Digest field puts a sharp limit on the > > > strength of a ZONEMD. > > [RW] > > > > I absolutely agree on specifying a minimum value. My question is how was > > the minimum length of "12 bytes" chosen? Is there some analysis performed > > that indicates that this is the right minimal value, or is this just a "12 > > bytes sounds like enough"? > > > > Regards, > > Rob > > > > > > > > > > Note that for the same reason there is a similar provision from 2006 > > > in RFC 4635, Section 3.1, point 4, which sets a minimum size of 10 > > > bytes for the hashes that appear in TSIG RRs. > > > > > > Thanks, > > > Donald > > > =============================== > > > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > > > 2386 Panoramic Circle, Apopka, FL 32703 USA > > > d3e...@gmail.com > > > > > > > ... > > > > > > > > Regards, > > > > Rob > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
