On Fri, Oct 9, 2020, 2:36 PM Wessels, Duane <dwessels= 40verisign....@dmarc.ietf.org> wrote:
> > > > On Oct 8, 2020, at 4: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: > > ---------------------------------------------------------------------- > > > > Thank for you this document. I found it interesting and it looks useful. > > > > I have a few comments that may improve this document for you to please > consider: > > > > Herein, SHA384 [RFC6234], with value 1, is the only standardized Hash > > Algorithm defined for ZONEMD records that MUST be implemented. When > > SHA384 is used, the size of the Digest field is 48 octets. The > > result of the SHA384 digest algorithm MUST NOT be truncated, and the > > entire 48 octet digest is published in the ZONEMD record. > > > > SHA512 [RFC6234], with Hash Algorithm value 2, is also defined for > > ZONEMD records, and SHOULD be implemented. When SHA512 is used, the > > size of the Digest field is 64 octets. The result of the SHA512 > > digest algorithm MUST NOT be truncated, and the entire 64 octet > > digest is published in the ZONEMD record. > > > > For consistency, perhaps change "with value 1" to "with Hash Algorithm > value 1"? > > Done. > > > > > > 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. > > > I know there has been some followup on this with Donald. In our earlier > conversations with him he wrote "96 bits seems to be a common minimum > length for disgests in the IETF although perhaps I have that impression > due to the common case of SHA-1 truncated to 96 bits." > > > > > > 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. Why not require recipients to verify all digests with recognized algorithms? 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. > > > > > > 3.1. Add ZONEMD Placeholder > > > > In preparation for calculating the zone digest, any existing ZONEMD > > records (and covering RRSIGs) at the zone apex are first deleted. > > > > I think that this places a requirement that all zone digests must be > > constructed at the same time. I suggest at least changing "zone digest" > to > > "zone digest(s)", but it might also be worth adding a sentence to > highlight > > that. > > I've changed it to "zone digest(s)" as you suggest. > > Strictly speaking, there is not a requirement that all digests must be > created > at the same time (in parallel). > > The reason for the placeholder is explained in the next paragraph, which > is to > ensure correct NSEC/NSEC3 records when the zone is signed with DNSSEC. > > > > > > I was also left wondering whether it is strictly required that the zone > digests > > must be deleted, or just that placeholder zone digests must be used in > their > > place during the calculation. E.g. what happens if a request is > received to > > fetch the ZONEMD record at the same time that it is being reconstructed? > > It is not strictly required to delete any existing digest first. The > ZONEMD records > are not included in the digest calculation. > > To address your questions around this, I suggest adding this text to > section 3, > before section 3.1: > > 3. Calculating the Digest > > The algorithm described in this section is designed for the common > case of offline DNSSEC signing. Slight deviations may be permitted > or necessary in other situations, such as with unsigned zones or > online DNSSEC signing. Implementations that deviate from the > described algorithm are advised to ensure that identical ZONEMD RRs, > signatures, and dential-of-existence records are produced. > > > > > 4. Verifying Zone Digest > > > > 5. Loop over all apex ZONEMD RRs and perform the following steps: > > > > ... > > > > My, perhaps mistaken, interpretation of these error reporting > instructions in > > this loop is that they really assume only a single ZONEMD RR. I.e., I > wouldn't > > expect the recipient to generate/return these errors if there were two > ZONEMD > > RR's and only one scheme/algorithm was was supported. Yes, there is > some text > > at the beginning of the entire algorithm that suggests what to do here, > but > > further guidance here may also be helpful. E.g. what does the server > return if > > there are two ZONEMD records and neither of them are acceptable for > different > > reasons? I'm presuming, perhaps incorrectly, that only a single error > > can/should be returned. > > Ben raised a similar point about this section, namely that it could result > in a lot of diagnostic output. > > Do you think it would be better remove those "SHOULD report" from each > individual > step and instead have a paragraph at the end that says the verifier SHOULD > report > the result of its verification and leave it at that? > > > > > > Regards, > > Rob > > > > Thanks for the review and comments! > > DW > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
