[secdir] Fwd: SECDIR review of draft-ietf-dnsop-dns-zone-digest-09

[Donald Eastlake <[e-mail]>]

Trying again with the correct subject line.

Sorry,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]

---------- Forwarded message ---------
From: Donald Eastlake <[e-mail]>
Date: Sat, Sep 12, 2020 at 1:20 PM
Subject: SECDIR review of draft-ietf-dnsop-dns-zone-review-09
To: [e-mail] <[e-mail]>,
<[e-mail]>
Cc: secdir <[e-mail]>


I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  Document editors and WG chairs should treat these comments just
like any other last call comments.

The summary of the review is Ready with Issues.

Notwithstanding that I have a lot of comments below, I think the idea
in this draft is a good one and look forward to its approval by the
IESG.


SECURITY ISSUES

1) The document claims that the presence of ZONEMD enables someone
holding the zone data to be able to determine its "authenticity" even
in the absence of DNSSEC. While it is not clear exactly what is meant
by "authenticity", I think this is misleading. I think that, at best,
without DNSSEC, you can test the data's "integrity". This is still
useful to protect again corruption and errors. But as I understand it,
"authenticity" takes a lot more machinery to test, such as the DNSSEC
mechanisms.

OLD (Section 1)
   It allows a receiver of the
   zone to verify the zone's authenticity, especially when used in
   combination with DNSSEC.

NEW
   It allows a receiver of the
   zone to verify the zone's integrity and, when used in
   combination with DNSSEC, its authenticity.

There is a similar problem with the first paragraph of Section 6.1.

2) The minimum size of the Digest Field, 1 octet, seems too small.
Typical minimum size for such a field in IETF protocols seems to be 96
bits or 12 octets, so that, at least with a strong hash function, you
have a reasonable resistance against brute force attacks. Also, while
it is fairly obvious, you might want to mention how a receiver
determines the length of the Digest Field.

OLD (Section 2.2.4)
The Digest field must not be empty.

NEW
The Digest Field MUST NOT be shorter than 12 octets. If it is, the
ZONEMD RR containing that short digest cannot be used to verify a
zone.  The length of the digest field is determined by deducting the
fixed size of the Serial, Scheme, and Hash Algorithm fields from the
RDATA size in the ZONEMD RR header.

3) SHA384 / algorithm agility
 -- here are some thoughts/comments on SHA384 and algorithm agility:

3a) SHA384 is a strong hash algorithm and is excellent for integrity
checking and the like but initially I was wondering if an algorithm with a
cryptographically stronger structure would be better if one is trying
to protect against active adversaries, even if the hash were shorter.
For example, HMAC-SHA2-256 which takes about as much computation as
SHA2-384. (Could be keyed by the "ZONEMD" concatenated with the zone
name.) But on further thought, DNSSEC strengthens things a lot. ZONEMD
will be covering not just the SOA serial but also the Signature
Expiration and Inception fields in the DNSSEC signatures. So, while I
haven't done a deep analysis, the more I think about it the more it
seems like a strong straightforward hash like SHA2-384 is OK.

3b) The draft lists only SHA2-384 but never says that it MUST be
implemented. Although it's fairly obvious, it seems to me the draft
should explicitly say that somewhere.

3c) The draft never says how long the Digest Field should be when you
use SHA384 -- presumably 48 bytes -- and what to do if the Digest
Field is the wrong length -- presumably not use the ZONEMD for
validation. (Presumably just add some text to 5.C. in Section 4.)

3c) SHA2-384 is just SHA2-512 with some different initialization
values and with the 512 bit output truncated to 384. Thus the
incremental effort of providing SHA2-512 in tiny if you have SHA2-384
(and vice versa). So, if SHA2-384 is mandatory, then you might as well
make SHA2-512 mandatory also since you get it for probably <1%
incremental effort. Having two mandatory algorithms with some people
using one and some the other would provide some real confidence that
implementations were actually looking at the Hash Algorithm Field,
could handle Digest Fields of different length, etc., and the
algorithm agility mechanisms might actually work. It currently looks a
bit like only lip service is being paid to algorithm agility.

3d) On algorithm agility generally: There is a reasonable provision in
the ZONEMD RR for a hash algorithm identifier.  But, given that this
is Standards Track I would have expected there to be hash algorithms
specified of different types with one a MUST implement and one a
SHOULD implement -- possible more but at least that. Blake or SHA3
would be example of a different algorithm type from SHA2. But I admit
that SHA2-384/512 is very strong and a break in it significant enough
to make much difference seems very unlikely.

4) There is no mention of local policy. If at some point there are
multiple hash algorithms and/or schemes specified (which could include
private use algorithms and schemes), a ZONEMD zone validator would
likely need a local policy as to which algorithm/scheme digest it will
pay attention to.  See, for example, the first paragraph of Section 4
which assumes any good digest should be good enough to validate the
zone for any verifier.

5) I'm not sure about the choice of "resilience" and "fragility" in
Section 6.3 without a bit more context as, at first, they seem
contradictory.  See attached for one suggestion on this.

It is great that examples are included but I did not check them for
correctness.


IANA CONSIDERATIONS

A number of points:

6. For both the Scheme and Hash Algorithm registries:
6a. Value 255 should be listed as Reserved.
6b. Values 2-239 should be listed as Unassigned.
6c. Having a "RESERVED" mnemonic seems odd, I don't think I've seen it
before. People usually just put a hyphen in the mnemonic column.
6d. In the rightmost "Reference Column", for things like Reserved or
Private Use, the usual thing is to either just put a hyphen ("-") or
to just say "[this document]". I don't think I have seen RFC 8126
given as a reference.
6e. Actually, 240-254 seems like a lot of values for Private Use. Why
would you need 15 private hash algorithms within one administrative
area? If you think there are going to be lots of private/proprietary
hashes (national vanity crypto?) that get used moderately widely,
there should be a provision for "vendor specific" hash algorithms
where the "Digest Field" actually starts with a "vendor" identifier.

7. I don't think all the references to RFC 8126 are needed. These are
all standard IANA terms. It would seem adequate to rename the
"Requirements Language" section to "Terminology" and add one sentence
saying "The terms Private Use, Reserved, Unassigned, and Specification
Required are to be interpreted as defined in [RFC8126]." Then all
other references to 8126 can be deleted. (You might need some DNS
related entries in a Terminology section anyway. I have significant
DNS background so I didn't feel any need for acronyms to be explained
or the like but that might not be true of a general reader.)


GENERAL

8. Sub-optimal ordering/grouping

8a. The sentence immediately before the Section 1.1 header, which give
the implementation requirement for ZONEMD, seems a little confusing
right after the preceding paragraph on DNSSEC. I think the sentence
should be moved up before the DNSSEC paragraph.

8b. In Section 1.1 on Motivation, I think only the first paragraph is
reasonably described by the section title. All of the rest of 1.1 is
"1.2 Alternative Approaches" or something like that.

9. Chronological terminology

I don't like all of the occurrences of "currently" or "at this time"
in the document. How likely are these phrases to be true 20 years
after this is published as an RFC? In many cases, this can be replaced
by using "herein" or the like except in Section 7 (Performance
Considerations) where some specific year or part of a year could be
given.

10. There are a number of instances of "must", "must not", or
"recommended" that I think should be in all capital letters. See
attached markup.

11. Verbosity

The document has a generally conversational style with some empty
filler words that don't add anything scattered here and there. While
this is all a matter of taste, I suggest the following:

11a. All occurrences of "certainly" and "Note that" should be
eliminated.

11b Instead of saying "x can be used to y" or "x is designed to do y"
just say "x does y" or the like.

11b. There are three statements in three different parts of the draft
(Sections 2., 3.1, and 4.) to the effect that
  "When multiple ZONEMD RRs are present, each
   must specify a unique Scheme and Hash Algorithm tuple."
I'm not sure what the best thing to do about this is but as long as
the validation section makes it clear that such redundant occurrences
mean none of them validate the zone, you are OK.

11c. See other instances of what I think is unnecessary wordiness and
suggested changes in the attached.

12. Having an Implementation Status section (Section 10) is good while
a draft is going through the approval process, but I think it is, as
indicated in RFC 7942, inappropriate in a resulting standards track
RFC. Furthermore, all of the disclaimer text given in RFC 7942 is
missing here. So, I believe similar disclaimer text should be added
and the RFC Editor should be requested to drop this section before
publication.


TYPOS

13. The only actual typo kind of errors I found were "the the" ->
"the" in Section 7.1 and "can not" -> "cannot" in Section 4.


ATTACHMENT

Taking into account the above and to make other editorial suggestions,
I have done an editing pass over the draft the results of which are
attached.  I hope you find it helpful.


Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]