Hi Ben, Thank you for the explanation and justification.
I personally find this sort of explanation really useful. I do wonder whether this sort of material might make a useful informational RFC at some point ... although of course everyone is very busy. But anyway, I think that we can regard my original comment as resolved. Regards, Rob > -----Original Message----- > From: Benjamin Kaduk <[email protected]> > Sent: 10 October 2020 04:25 > To: Rob Wilton (rwilton) <[email protected]> > Cc: [email protected]; Tim Wicinski > <[email protected]>; [email protected]; <[email protected]> > <[email protected]>; The IESG <[email protected]>; Donald Eastlake > <[email protected]>; Roman Danyliw <[email protected]> > Subject: Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns- > zone-digest-12: (with COMMENT) > > 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 > > [email protected] > > > > On Fri, Oct 9, 2020 at 5:23 AM Rob Wilton (rwilton) <[email protected]> > wrote: > > > > > > Hi Donald, > > > > > > > -----Original Message----- > > > > From: Donald Eastlake <[email protected]> > > > > Sent: 09 October 2020 00:47 > > > > To: Rob Wilton (rwilton) <[email protected]> > > > > Cc: The IESG <[email protected]>; draft-ietf-dnsop-dns-zone- > [email protected]; > > > > Tim Wicinski <[email protected]>; <[email protected]> > <[email protected]>; > > > > [email protected] > > > > 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 > > > > <[email protected]> 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 > > > > [email protected] > > > > > > > > > ... > > > > > > > > > > Regards, > > > > > Rob > > _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
