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

[Tim Wicinski <[e-mail]>]

Michael

Thanks for reviewing the -06 changes and thanks for dropping your
objections.
I will work with the authors on cleaning up the text.

As for your comments on Standards Track, as a chair and not a chair, I have
moved back toward not making this Standards Track, but Informational.
I will need to talk with the other chairs on this more.

tim




On Fri, May 22, 2020 at 3:30 PM Michael StJohns <[e-mail]>
wrote:

> 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.
>
>
>
>
>
>