Dear IESG, I believe all outstanding comments and concerns have now been addressed, so revision -14 has been posted.
DW > On Oct 15, 2020, at 3:38 AM, Rob Wilton (rwilton) <rwil...@cisco.com> wrote: > > Hi Duane, > > That looks good. Thanks for accommodating. > > Regards, > Rob > >> -----Original Message----- >> From: iesg <iesg-boun...@ietf.org> On Behalf Of Wessels, Duane >> Sent: 14 October 2020 13:35 >> To: Rob Wilton (rwilton) <rwilton=40cisco....@dmarc.ietf.org> >> Cc: draft-ietf-dnsop-dns-zone-dig...@ietf.org; Tim Wicinski >> <tjw.i...@gmail.com>; dnsop@ietf.org; dnsop-cha...@ietf.org; The IESG >> <i...@ietf.org> >> Subject: Re: Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone- >> digest-12: (with COMMENT) >> >> >> >>> On Oct 12, 2020, at 8:56 AM, Rob Wilton (rwilton) >> <rwilton=40cisco....@dmarc.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. >>> [RW] >>> >>> Okay, taken in conjunction with 2.2.3 that didn't seem clear to me. My >> reading is that the sender SHOULD only send one, and [everyone] MUST >> support SHA384, effectively implying that is SHA384 that MUST be sent ... >> Perhaps the RFC 2119 language in section 2.2.3 needs to be restricted to >> receivers processing ZONEMD records? ... or some other way to convey the >> difference in requirements on algorithm implementation between senders and >> receivers. >>> >> >> >> Hi Rob, >> >> To address this, here is what we suggest: >> >> In sections 2.2.2 and 2.2.3, rather than saying "MUST/SHOULD be >> implemented" we'll say "MUST/SHOULD be supported by implementations." >> >> The paragraph about multiple digests at the start of section 2 will be >> moved to this new section 2.5: >> >> 2.5. Including ZONEMD RRs in a Zone >> >> The zone operator chooses an appropriate hash algorithm and scheme, >> and includes the calculated zone digest in the apex ZONEMD RRset. >> The zone operator MAY choose any of the defined hash algorithms and >> schemes, including the private use code points. >> >> The ZONEMD RRSet MAY contain multiple records to support algorithm >> agility [RFC7696]. [RFC Editor: change that to BCP 201] When >> multiple ZONEMD RRs are present, each MUST specify a unique Scheme >> and Hash Algorithm tuple. It is RECOMMENDED that a zone include only >> one ZONEMD RR, unless the zone operator is in the process of >> transitioning to a new scheme or hash algorithm. >> >> >> DW >> >> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
