Hi Brian, I see what you're saying. For implementations that treat the truncated digest as a zone parsing failure then example A.3 is not valid.
DW > On Feb 11, 2021, at 11:19 AM, Wellington, Brian <[email protected]> wrote: > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > Hi Duane, > > I’m not sure if I completely agree with this analysis. The issue isn’t about > validation; it’s about parsing the presentation format. The RFC says: > > When SHA384 is used, the size of the > Digest field is 48 octets. The result of the SHA384 digest algorithm > MUST NOT be truncated > I’d interpret that as requiring (or at least allowing) a zone file parser to > reject the example record as malformed, and fail to parse the zone. Section > 2 is describing the format of the record itself, not the process of > validation, so I would expect the specific text in 2.2.3 to be applicable to > parsing the record, not validating it. > > Thanks, > Brian > >> On Feb 11, 2021, at 10:25 AM, Wessels, Duane <[email protected]> wrote: >> >> Brian, >> >> Thank you for reporting this. Indeed this example SHA384 digest should have >> 48 octets, although the A.3 example zone as a whole is still valid because a >> verifier will either exclude the ZONEMD RR in question either because of the >> private-use scheme or because it is truncated. Since the example wasn't >> intended to include a truncated digest, we think the errata should be >> accepted and corrected. Proposed correction: >> >> example. 86400 IN ZONEMD 2018031900 241 1 ( >> e1846540e33a9e41 >> 89792d18d5d131f6 >> 05fc283e8136a8ed >> 924937852d0076a3 >> fd5cd859c4265eaf >> a8dd75c61e3dc079 ) >> >> DW >> >> >>> On Feb 10, 2021, at 1:48 PM, RFC Errata System <[email protected]> >>> wrote: >>> >>> Caution: This email originated from outside the organization. Do not click >>> links or open attachments unless you recognize the sender and know the >>> content is safe. >>> >>> The following errata report has been submitted for RFC8976, >>> "Message Digest for DNS Zones". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> https://secure-web.cisco.com/1dYEy0TvU88Njg8yutPU4SwLggJQyQtMtCFHusS4a4nwHHkd3A6abr3omPJ9EK6U3LD99P6cBoRMQRg-6Qj9F83dYEUwv96xU0ZwpAXLazBepRocQLDO8SepHSeqtdZG2kjMy8KxUal-6tWtES4U88sanGAhpTvqbNvYpBaChoyDTB8PjjI0GnW8u0axgqd-BA6e4p8QHMODXQqiosSeXaDTrRmXEn4O3Ftg-2Mg-GdvlRjRjTBwrs4Q09iRyKBYb/https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6425 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Brian Wellington <[email protected]> >>> >>> Section: A.3 >>> >>> Original Text >>> ------------- >>> example. 86400 IN ZONEMD 2018031900 241 1 ( >>> e1846540e33a9e41 >>> 89792d18d5d131f6 >>> 05fc283e ) >>> >>> >>> Corrected Text >>> -------------- >>> <A ZONEMD record with a digest of length 48> >>> >>> Notes >>> ----- >>> 2.2.3 defines Hash Algorithm 1 as SHA384, and says that "the size of the >>> Digest field is 48 octets". There is nothing in 2.2.3 (or 2.2.2, where >>> Scheme is defined) that indicates that Scheme and Hash Algorithm are >>> dependent on each other, so the fact that the Scheme value (241) is private >>> should have no effect on the digest computed by Hash Algorithm 1. >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC8976 (draft-ietf-dnsop-dns-zone-digest-14) >>> -------------------------------------- >>> Title : Message Digest for DNS Zones >>> Publication Date : February 2021 >>> Author(s) : D. Wessels, P. Barber, M. Weinberg, W. Kumari, W. >>> Hardaker >>> Category : PROPOSED STANDARD >>> Source : Domain Name System Operations >>> Area : Operations and Management >>> Stream : IETF >>> Verifying Party : IESG
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
