The following excerpts allow for and even encourage software written
against this document in its present form to behave in ways that will
hinder adoption of future changes, and should probably be altered in
order to foster the desired compatibility.
Section 2 requires "Each ZONEMD RR MUST specify a unique Digest Type",
which means that a name server written against this document would be
justified in rejecting a zone containing both a SHA384 ZONEMD RR with
Reserved=0 and a SHA384 ZONEMD RR with Reserved!=0.
Section 2.2 declares that "The [presentation format] Reserved field MUST
be represented as an unsigned decimal integer set to zero", which means
that software written against this document would be justified in
rejecting a master file containing a ZONEMD RR with nonzero Reserved.
In Section 3.2 ZONEMD placeholder records, "The Digest field MUST be set
to all zeroes and of length appropriate for the chosen digest
algorithm", which may poorly accommodate variable-length digests and
result in interoperability issues.
Section 1 anticipates "a name server can verify the zone data it was
given and refuse to serve a zone which fails verification" but Section 4
declares that digest verification MUST NOT be considered successful if
"If the zone contains more than one apex ZONEMD RR" or "If the Reserved
field value is not zero", which means that software written against this
document would be justified in rejecting a zone containing a ZONEMD
described by either of those conditions. This is the crux of the
compatibility concerns, and I think it would be best corrected by
restricting step 4 failures to zones containing "more than one apex
ZONEMD RR /with Reserved field equal to zero and the same Digest Type/"
and updating later steps such that they apply for each ZONEMD RR and
failures mean "digest verification MUST NOT be considered successful
/for that RR/".
On 9/10/19 19:18, Wessels, Duane wrote:
Thanks Shane & George, I agree this needs some clarification.
Something thats probably missing from the document is that in any future
revision of ZONEMD we expect backwards compatibility. For this version, it is
expected that Reserved is set to zero. In a future version, if the formerly
reserved field can have non-zero values, then a value of zero there should
produce the exact same hashes as it does in this version.
I gave a presentation at DNS-OARC last year with some experiments in making
large dynamic zones more efficient. There I used the reserved field to encode
the depth of a Merkle tree. A depth of zero corresponds to effectively no tree
which is the same as described in the current version.
Recently Mukund posted here a proposal of his for how to store zone data in
memory in a ZONEMD-compatible way. While slightly different than my idea, I
believe his also could be implemented in a way such that the reserved field
encodes what the consumer needs to know about how the data should be stored and
the hash computed for interoperation.
If we agree that a value of zero in this field produces the same hash value in
this version and future versions of ZONEMD, then shouldn't we say that it is an
error to have non-zero values at this time? If we say it is acceptable to
ignore non-zero values at this time, then it would lead to incompatible hash
values in the future version.
DW
On Sep 9, 2019, at 2:13 AM, George Michaelson <g...@algebras.org> wrote:
This is a not uncommon problem in 'make this protocol work in future' spec. It could say "for
version ZERO of this protocol" and then say "future versions of this protocol should
stipulate what other values mean, and how this affects handling of all-zeros state, and other
states"
Saying "must not validate" baldly basically says "will always be zero" to me
-Which I think is what you're saying!
_G
On Mon, Sep 9, 2019 at 3:04 PM Shane Kerr <sh...@time-travellers.org> wrote:
Duane,
On 2019-09-06 02:01, Wessels, Duane wrote:
With this version the authors feel that it is ready for working group last call.
Sorry for a late comment, but I decided to give this one thorough last
read-through.
I'm a little concerned that the way the Reserved field is described may
make adoption of later versions of ZONEMD difficult. The relevant text:
2.1.3. The Reserved Field
The Reserved field is an 8-bit unsigned integer, which is always set
to zero. This field is reserved for future work to support efficient
incremental updates.
.
.
.
4. Verifying Zone Message Digest
.
.
.
7. The Reserved field MUST be checked. If the Reserved field value
is not zero, verification MUST NOT be considered successful.
The question is, what can a zone producer do to support both this
version of ZONEMD as well as a new version? Adding a non-zero Reserved
ZONEMD value will break any implementation using this specification.
I think what would be ideal is for non-zero Reserved values to be ignored.
If we treat non-zero Reserved the same as unknown algorithms (that is,
using placeholders) will that be okay? It may complicate generating
compatible ZONEMD in future ZONEMD implementations. With the envisioned
incremental version I think it will be fine; if you want both a
full-zone and incremental ZONEMD then it will indeed be complicated, but
I think probably few zones will need that. I have no idea whether using
the placeholder technique will work for more weird and wonderful later
versions.
I suppose it is okay to reject the use case and not worry about
compatibility, since we expect the incremental version to be used mostly
for large zones where the current ZONEMD simply won't work... 🤔
Cheers,
--
Shane
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
