On Wed, Jan 15, 2020 at 7:06 AM Paul Hoffman <paul.hoff...@icann.org> wrote:

> On Jan 15, 2020, at 12:14 AM, Shane Kerr <sh...@time-travellers.org>
> wrote:
> >
> > Duane,
> >
> > On 13/01/2020 19.26, Wessels, Duane wrote:
> >>> On Jan 8, 2020, at 3:55 PM, Michael StJohns <m...@nthpermutation.com>
> wrote:
> >>> There's also the case that future ZONEMD schemes may need a different
> format for the digest field.   E.g. one approach to dealing with
> incremental changes is to have a NSEC like ZONEMD record which covers
> hashes only across a range of names.
> >> We think that the currently documented RR format will solve most use
> cases - since the digest field is variable length, it already provides a
> lot of flexibility for future uses, by defining additional Digest Types.
> Anything which cannot be solved with this format seems like it would be a
> sufficiently different protocol that it would deserve a new RRtype and
> document.
> >
> > Honestly thinking about it more, I'm not even sure we should consider
> supporting an incremental version of zone digests in ZONEMD at all. There's
> no harm in introducing a new type with its own syntax and semantics if we
> tackle that problem in the future.
> >
> > Some agility is needed to add new hashing algorithms, but beyond that I
> think maybe we should consider ZONEMD perfect in every way and not ever
> needing to be revised. 😉
>
> Thank you for voicing this, Shane. Given that any incremental digest
> mechanism will have at least a few significantly different processing
> rules, I strongly suspect that it would be easier for implementors if there
> were two different RRtypes. The requests to have both sets of processing
> rules under one RRtype seems actively dangerous from a security perspective.
>

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

Brian
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to