Re: [DNSOP] [Ext] future-proofing (Re: Working Group Last Call for: Message Digest for DNS Zones)

[Michael StJohns <[e-mail]>]

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.