Re: [DNSOP] Second Working Group Last Call for: Message Digest for DNS Zones

[Michael StJohns <[e-mail]>]

Hi -

With the change to remove ZONEMD from the calculation (apparently in 
-06), I no longer have any objections related to future proofing.

But, with the change, the text needs some additional clean up.

Instead of the current section 3 - use something like this:

 >>
3. Updating the Zone for ZONEMD RRs

3.1 "Step 1 - remove any existing apex ZONEMD RR from the zone"

3.2 "Step 2 - for each scheme, form a canonical representation of the 
zone according to the scheme.  The canonical representation for the 
SIMPLE scheme is listed in <> below."

3.3S "Step 3 (SIMPLE):  For each digest type in the SIMPLE scheme, 
calculate the digest over the canonical representation and form the 
appropriate ZONEMD RR for later inclusion" [Note: Other Schemes may have 
other processing at this point]
3.3O "Step 3(Other): For any other scheme/digest pair form the 
appropriate ZONEMD RRs and it them to the set for later inclusion.

3.4. "Step 4: Add each of the ZONEMD RRs formed in step 3 to the zone"

3.5. "Step 5 (Optional):  Sign the zone adjusting NSEC/NSEC3 records as 
appropriate to account for the existence of the ZONEMD RRSet".


4. Canonical representation and Digest Calculation for the SIMPLE 
scheme. (move the  old 3.3, 3.4 and 3.5 sections under this heading).
 >>


Note:   The presence or absence of _provable_ DNSSEC for the ZONEMD RRs 
is irrelevant to whether or not the zonemd rr set can be verified.  It 
would seem to me that if you have a chain of DNSKEY RRs back to a trust 
point, you can verify the zonemd RR whether or not the zone claims the 
records should exist.     NSEC records say that the record SHOULD exist, 
but AFAICT NSEC records aren't actually checked if the records do 
exist.  That may have changed from the original model, but I mention it 
with respect to  section 4, first bullet which reads as if the 
expectation is the important thing rather than actual signature data.

I'm still not a big fan of this as a standards track document as I don't 
feel it provides enough general benefit nor does it provide a standard 
and programmatic answer to "what do I do if it doesn't verify", but I'm 
no longer adamant it needs to be experimental as it no longer forces a 
contract for future digesting models.

Later, Mike



On 3/9/2020 5:24 PM, Michael StJohns wrote:
> On 3/9/2020 4:46 PM, Wessels, Duane wrote:
>>> Michael StJohns pointed out (Feb 25) that a verifier that does not
>>> recognise a particular
>>> ZONEMD Scheme and/or Hash Algorithm may be unable to create the
>>> required placeholders,
>>> and therefore unable to perform a verification using any
>>> (Scheme,Algorithm) at all.
>> I don't believe that to be the case.  For the unknown schemes/algorithms
>> the recipient simply replaces how ever many octets the received ZONEMD digest
>> had with all zeros.
>>
>>
>>
>
> As of right now, I don't believe the current format is future proofed.
>
> Current encoding:
>
> 0x01 - simple
> 0x01 - SHA384
> 48 bytes of digest.
>
> 0x01 - simple
> 0x02 - SHA512
> 64 bytes of digest.
>
> 0x02 - Complex
> 0x00 - Ignored - mainly because I'm forced to have it here because of 
> the SIMPLE scheme - it doesn't specify a digest type.
> [Opaque values that describe the complex scheme - e.g. btree 
> description, partial hashes, selection matrix of RRs I actually care 
> about etc]
> [More opaque values that are the various digest(s)]
>
> These are OPAQUE from a receiver that only understands SIMPLE.
>
> For the latter scheme, I want to include the first part of the opaque 
> values in the various hash calculations.   But the SIMPLE scheme will 
> set them to zero for its own calculations?   And I have to do special 
> things for scheme 1 to do my calculations. AND I have to know that 
> digest 0x02 requires 64 bytes of zero for the calculation even if I'm 
> only able to verify SHA384 digests.  Any error in the formation of the 
> digest 0x02 digest field or scheme 0x02 data field means that the 0x01 
> digest won't verify.  Ditto for any formation for the scheme 2 complex 
> digest relative to the Scheme 1 digests.  This makes all digests 
> interdependent which I believe was not desired.
>
> I see no benefit to including the ZONEMD RR in any digest calculation 
> with our without placeholdering it.
>
> Just omit any ZONEMD RR from the calculation and be done with it.  
> Make ALL ZONEMD RRs independent from each other.
>
>
>
>