Hi Joe, Thanks for the detailed review.
> On Oct 29, 2018, at 2:45 PM, Joe Abley <jab...@hopcount.ca> wrote:
>
> Hi all,
>
> I have read draft-wessels-dns-zone-digest-04.
>
> General Summary
>
> I find this document to be generally well-written, clear and unambiguous.
>
> ...
>
> Nits
>
> The document contains a normative reference to RFC 3658 which I think is fine
> in the context in which it used.
>
> The document makes frequent reference to "zone file" which I find
> anachronistic. Maybe it's just me, but I think we're talking about a zone
> object or a zone structure, and the phrase "zone file" to me suggests that
> we've all tripped down a time vortex, it's 1993 and Vixie hasn't even bought
> his first tractor yet.
Yes, Mukund pointed this out as well and it is fixed.
>
> This document uses "RRset" and "RRsets" rather than "RRSet" and "RSets". The
> RFC editor seems to have no style guide for this, but my impression is that
> RRSet is slightly preferable (not to me, but I'm happy to sheep with the
> consensus). Just thought I'd mention it.
Changed to RRSet and RRSets
>
> Commentary
>
> Section 1.2
>
> I don't understand the benefits of suggesting that verification of a zone
> digest "would be implemented in name server software". The inference is that
> software that normally concerns itself with responding to queries should be
> extended to check zone digests, which seems unnecessary and contentious; in
> general it's not the libraries or executables in which the software live that
> is important but rather that there be a trusted relationship between the
> verification process and the software that consumes the validated zone data.
> I think the final paragraph could just be removed.
The thinking here is that its best to have the verification part as close to
the serving part as possible. If there is agreement that this text is an
unnecessary distraction, then it would be okay
to remove it. It doesn't affect the protocol itself.
The trusted relationship is key, I think. I have heard people suggest, in the
context of "hyperlocal root," that the perhaps all these millions of Internet
access routers and access points should serve the root zone. These devices
have notoriously bad security, and I think it would be a mistake to assume that
zone data read from its flash storage does not need to be verified before it is
served.
>
> I think supporting multiple ZONEMD records per zone using different digest
> types might be useful if it was specified in such a way that it ensured that
> consumers of the ZONEMD RRSet should not fall back to other digest types if
> their preferred type did not work. I understand the concern about downgrade
> attacks in general, but in this case if the ZONEMD RRSet is signed, a
> downgrade attack would require the ability to replace the covering RRSIG, and
> if you can do that you don't need to force a downgrade, you can just replace
> the ZONEMD RRs' RDATA with your own and re-sign illicitly.
I think you might be the first person to argue for supporting multiple ZONEMD
algorithms per zone. I actually expected more.
What you're saying is that a recipient would have a list of supported
algorithms, ordered by its own preference. It finds the most-preferred ZONEMD
RR, and uses only that one for verification, ignoring all others. Correct?
>
> I think it would be handy to specify a short name for each of the four fields
> used in the ZONEMD RDATA, e.g. as was done in 1035 with SOA.
I'm open to it.
>
> Section 2.1.3
>
> You might specify what action a consumer of a ZONEMD RRSet is required to
> take (following this specification) in the event that it finds an RR with
> reserved field != 0.
To me this belongs in the Verifying Zone Message Digest section:
The Reserved field MUST be checked. If the Reserved field value
is not zero, verification MUST NOT be considered successful.
>
> Section 2.2
>
> You don't specify the representation of unsigned decimal integers clearly
> enough for me to know whether leading zeros are tolerated or preferred.
I emulated RFC 4034 here. I guess I'm not aware of any decimal presentation
fields that prefer leading zeroes. How would you like to see it specified?
> The example in section 2.3 makes it clear that the venerable tradition of
> using round brackets to encapsulate multi-line presentation formats is
> expected; I can't remember just now whether that's written down anywhere, but
> if it isn't perhaps it's worth a mention.
RFC 1034 sayeth:
3.6.1. Textual expression of RRs
...
In this format, most RRs are shown on a single line, although continuation
lines are possible using parentheses.
> Section 3.1.2
>
> I think that in the specific case mentioned the two SOA RRs are expected to
> be identical. I wonder whether it's worth generalising the advice to confirm
> that where there are multiple identical instances of RRs within a single
> RRSet (same owner name, RRType, RDATA, class, TTL) only one is included in
> the calculation of the zone digest?
It sounds wrong to me to say that identical instances of RRs would not be
allowed in a zone.
> Perhaps SOA is the only example of this. For the precise reasons given,
> calling SOA out as a well-known example would make sense even if the
> specification was generalised as suggested above.
Mukund informed me that repeated SOAs are likely less common than I believed,
and probably due to
thinking in terms of "zone files" rather than zones. Perhaps the bullet about
multiple SOAs should
just be removed.
>
> Section 3.3
>
> I don't see the point of ZONEMD in the absence of DNSSEC. This section to me
> suggests that there might be a point to it. I don't know what that might be.
The only point would be so that you could discover accidental zone corruption,
rather than intentional fiddling.
>
> Section 3.4.1
>
> See commentary on Section 3.1.2.
>
> I think the situation suggested by the question for discussion in this
> section only arises if you are querying piecemeal for ZONEMD RRSets and not
> starting with the job of verifying the digest over a whole zone. But I
> haven't thought very hard about that, as should be obvious from the frequency
> of hand oscillation in the commentary above on section 3.2.
(this is in reference to occluded data). Per discussions with others I am
convinced that occluded data is still considered part of the zone, and should
be included in the digest.
>
> Section 4
>
> As above, I don't think it's useful to specify verification of zone digests
> in the absence of DNSSEC. If there's no chain of trust to the apex DNSKEY
> RRSet, I think consumers SHOULD NOT infer anything about zone integrity.
I'd like to hear from others on this point.
>
> Section 5
>
> I am mainly ambivalent about the RESERVED field. I generally it would be
> better to burn another type code for a new mechanism, but I understand the
> consequent trade-off of having to specify carefully what behaviour should be
> intended in zones that contain both, perhaps where one verifies and one does
> not. Given that the authors already have some code and experimental results
> of using Merkle trees that seem promising, however, if pressed to have an
> opinion I would suggest keeping it.
>
> Section 6.1
>
> I think you should specify precisely what row you want to insert into that
> table as a kindness to the IANA (e.g. specify the TYPE, Value, Meaning and
> Reference). If you get an early assignment then the appropriate documentation
> will be in the corresponding template and this section can just be removed.
>
> Section 6.2
>
> If you want the IANA to create a new registry they need more information than
> is supplied here. RFC 8126 contains guidance. I'm not convinced,
> incidentally, that a new registry is required; seems to me that it would be
> cleaner to reuse the DS RR Digest Type table, but perhaps this has already
> been discussed and the implementation status thing is real.
Good ideas, thanks.
DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
