On 1/15/2020 1:25 PM, Brian Dickson wrote:
I don't disagree with the notion of a strong differentiator between
ZONEMD and any other digest, either using RRTYPE or with an
underscore-prefix name.
However, there is a Heisenberg problem, which is that any other digest
type needs to be excluded from the ZONEMD calculation (and vice versa).
So, from the future-proofing standpoint, I think one of the two
methods needs to be picked (I think RRTYPE is fine), and a range of
types needs to be reserved for future zone digests.
I'd suggest small range (i.e. more than 1, maybe 4), and include the
reservation in this document with IANA instructions to that effect.
The exclusion of that reserved future-use digest range should be baked
into the ZONEMD calculation itself, so future digests don't require an
update to ZONEMD, and don't result in incompatible deployed digest
implementations.
(In other words, future-proof ZONEMD itself.)
*sigh* I think its a co-existence issue here. I don't think you should
have two different (calculation-wise) ZONEMD-like RRSets in the same
zone for the reasons you've mentioned. I don't think that reserving RR
types is the right way of doing things and I'm not sure how you'd write
the IANA guidance to cover the later assignment of those type numbers.
It's possible that we can tweak this a bit and get around the problem.
So maybe:
1 byte - Scheme - 1 == SIMPLE
Which has a body of
1 byte - digest - 1 == SHA384, a
followed by N bytes of the appropriate digest length.
And either "Only one Scheme shall be used per zone. A receiver shall
consider a zone containing multiple schemes as invalid for the purposes
of this document". or "The SIMPLE scheme shall exclude any ZONEMD RR
of a non-SIMPLE scheme from the digest calculation for the SIMPLE
scheme" or "ZONEMD digest calculations for any scheme shall only include
ZONEMD RRs with matching schemes - no placeholder records for non-scheme
ZONEMD rrs shall be added to the calculation".
I think the last of these three is probably the right approach.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
