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