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.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
