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

["Wessels, Duane" <[e-mail]>]

Thanks Don for the extensive review!  tl;dr, we did accept most/many of your suggestions already, except these items may warrant further discussion:

- minimum digest length
- more hash algorithms than SHA-384
- local policy when verifying multiple digests
- implementation status section

More responses inline below.

DW



> On Sep 12, 2020, at 6:53 PM, Donald Eastlake <[e-mail]> wrote:
> 
> 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.

A good change, thanks.

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

Accepted your text in that section as well.

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

I'm not necessarily opposed to a minimum digest size.  Do you envision
any complications with private use algorithms though?  It seems a little
strange to allow private use algorithms whose digest value could be anything,
but requiring a minimum size (which could then simply be padded I know).


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

Understood.

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

Agreed.  Thanks for the text.

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

Added.

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

In an earlier version of the draft, four algorithms were defined, although
none "past" SHA-384.  There was a (Oct 2018) discussion to make SHA-384
the mandatory algorithm and drop all the weaker ones.

I'm not necessarily opposed to adding more mandatory-to-implement algorithms
if there is working group consensus about that, but it feels like a pretty
significant and late change?


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

Same as above.

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

The draft-ietf-dnsop-dns-zone-digest-00 version did have the following text that spoke to this: 

>   It is RECOMMENDED that implementations maintain a (possibly
>   configurable) list of supported Digest Type algorithms ranked from
>   most to least preferred.  It is further RECOMMENDED that recipients
>   use only their most preferred algorithm that is present in the zone
>   for digest verification.
> 
>   As a matter of local policy, the recipient MAY require that all
>   supported and present Digest Type algorithms verify the zone.

There was a thread on DNSOP where we had agreement to
take those two paragraphs out:

https://mailarchive.ietf.org/arch/msg/dnsop/RFCklH7Lx00bL-tOVRCAc0j5ftw/

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

Suggestion accepted.

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

Thanks, the tables have been changed per your suggestions.


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

It seemed a reasonable amount to us, but if others think it should be
smaller that shouldn't be a problem.

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

Thanks, this has been fixed.

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

Done.

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

Done.

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


Done.


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


Done.


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

The authors feel it could be useful, even though it is expected to
become out-of-date.   Looks like some other published RFCs have kept
their Implementation Status sections, sometimes as an appendix?

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

Thank you, we did find it very helpful.