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://www.rfc-editor.org/errata/eid6425
>> 
>> --------------------------------------
>> 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
> 

_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to