> On Mar 25, 2019, at 6:53 AM, Matthew Pounsett <m...@conundrum.com> wrote: > > > > On Wed, 13 Feb 2019 at 22:56, Wessels, Duane > <dwessels=40verisign....@dmarc.ietf.org> wrote: > The only change to this document since -05 is to note that ZONEMD has been > allocated RR type code 63 by IANA following an expert review back in December. > > I haven't reviewed this for a couple of revisions, so some notes here that > don't apply to the new codepoint. :) . I've tried doing some searches of the > discussion history to make sure I'm not raising points already addressed, but > my apologies if I've missed something. > > Section 2 discussion: I was initially ambivalent about whether multiple > ZONEMD records should be allowed with different digest types. Having gone > back and re-read some of the discussion, I'm persuaded that it would be > beneficial to allow multiple digest types to be used on the same zone > instance. I think we'd want to have a bunch of discussion about the details > in order to keep code complexity under control, though.
Thanks Matt, this seems to be the consensus, so we'll be adding some text about how to interpret multiple ZONEMDs. > > Section 3.2. discussion: Unless there's a potential benefit to non-apex > ZONEMD records that I'm not seeing, I think it makes sense to forbid them. > Was there a particular thing that could be enabled by that, which prompted > the suggestion? I'm not aware of any use for non-apex ZONEMDs. I think it comes down to the choice to either be liberal or strict in what you accept. > > In 3.4.1 would it make sense to include a sentence explaining the catch-22 > that would result if the RRSIG covering the ZONEMD record were included in > the digest? Added, thanks. > > In section 4, I suggest replacing all of the instances of "provably > [un]signed" with "provably [in]secure". Good catch, thanks. > Section 5 discussion: I can't remember if I commented on this bit before or > not, but just in case.. I support keeping the reserved field. It seems to me > that if we have to get a new type for an incremental-friendly version of > ZONEMD that we're going to have implementation fragmentation and a migration > issue. Especially if we don't allow multiple ZONEMD records, I can imagine > it being difficult to have both in the zone at once, and that it could be > hard to specify what should happen if an operator wants to migrate from > ZONEMD v1 to ZONEMD v2 without knowing which one the consumers of their zone > support Appreciate the feedback. DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
