On Fri, Oct 09, 2020 at 06:36:28PM +0000, Wessels, Duane wrote: > > > > On Oct 8, 2020, at 4:18 AM, Robert Wilton via Datatracker > > <nore...@ietf.org> wrote: [...] > > 2. The ZONEMD Resource Record > > > > It is > > RECOMMENDED that a zone include only one ZONEMD RR, unless the zone > > publisher is in the process of transitioning to a new Scheme or Hash > > Algorithm. > > > > I'm not quite sure how well this fits with sections 2.2.3 restriction that > > SHA384 MUST be implemented, and SHA512 SHOULD be implemented. As a > > recipient > > of the zone info I understand that I would need to implement both, but as a > > sender am I allowed to only send SHA512, or both, or must I always send > > SHA384? > > As sender (publisher) you are allowed to publish whatever you want. > > The purpose of the recommendation above is to hopefully avoid the situation > where multiple records are published (with both types) on an ongoing basis. > That is something we observe with DS records quite often. For example, > 750 TLDs today publish both SHA1 and SHA256 digest types as DS records in > the root zone. This new paragraph has been added to the security > considerations: > > 6.2. Use of Multiple ZONEMD Hash Algorithms > > When a zone publishes multiple ZONEMD RRs, the overall security is > only as good as the weakest hash algorithm in use. For this reason, > Section 2 recommends only publishing multiple ZONEMD RRs when > transitioning to a new scheme or hash algorithm. Once the transition > is complete, the old scheme or hash algorithm should be removed from > the ZONEMD RRSet.
While I'm happy to see this statement made, I do want to note that the actual properties here have some complex interplay, and "only as good as the weakest hash algorithm in use" may only be strictly true in certain scennarios. (So, in the general case, it is a true statement, but there may be certain cases in which it does not hold.) In particular, since DNSSEC signs the whole RRset, it does not seem like it is possible (without some other attack) to modify things so that the ZONEMD with a different hash algorithm is not visible while retaining the RRSIG. And if you have a signed zone with a weak hash for ZONEMD, producing a different zone that collides the ZONEMD will probably not retain all the RRSIGS on the other records (though could plausibly retain most of them). So, it's complicated, but I'm not sure that we really need to get into the specifics in this document. Personally, I'm fine keeping this text as-is, but I did want to note the subtlety involved. -Ben _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
