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

From: Donald Eastlake <[email-masked]>
Date: Sat, 12 Sep 2020 13:20:01 -0400

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   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 12 Sep 2020 21:53:08 -0400

Trying again with the correct subject line.

Sorry,
Donald

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

SECURITY ISSUES

OLD (Section 1)

NEW

OLD (Section 2.2.4)

NEW

IANA CONSIDERATIONS

A number of points:

GENERAL

11. Verbosity

TYPOS

ATTACHMENT

Thanks,
Donald

---

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 15 Sep 2020 15:38:31 +0000

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 <[email-masked]> wrote:
> 

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.

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

> seems like a strong straightforward hash like SHA2-384 is OK.

Understood.

> should explicitly say that somewhere.

Agreed.  Thanks for the text.

> validation. (Presumably just add some text to 5.C. in Section 4.)

Added.

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

> to make much difference seems very unlikely.

Same as above.

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/

> contradictory.  See attached for one suggestion on this.

Suggestion accepted.

> to just say "[this document]". I don't think I have seen RFC 8126

Thanks, the tables have been changed per your suggestions.

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

> or the like but that might not be true of a general reader.)

Thanks, this has been fixed.

> "1.2 Alternative Approaches" or something like that.

Done.

> Considerations) where some specific year or part of a year could be

Done.

> "recommended" that I think should be in all capital letters. See

Done.

> suggested changes in the attached.

Done.

> and the RFC Editor should be requested to drop this section before

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?

> attached.  I hope you find it helpful.

Thank you, we did find it very helpful.

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 15 Sep 2020 22:34:40 -0400

Hi Duane,

Thanks for accepting most of my suggestions.

See my responses below at <de> on the items we are still discussing.

On Tue, Sep 15, 2020 at 11:38 AM Wessels, Duane <[email-masked]>
wrote:

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

> but requiring a minimum size (which could then simply be padded I know).

<de> Well, it looked to me like the draft already had a minimum Digest
field, namely one octet, since it said the Digest Field couldn't be empty.
As I recall, the digest didn't say what to do if the Digest field was zero
length but I presume it would mean that the ZONEMD RR was malformed and
thus could not be used to validate a zone. Seems like the minimum length
would apply to private use algorithms also. See Section 5.2.2.1 of
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc2845bis-09

> > -- here are some thoughts/comments on SHA384 and algorithm agility:
...

> significant and late change?

<de> I agree it is a significant change in the draft. But, as I say, if you
have SHA-384 you have 99+% of the crypto code you need for SHA-384 and
SHA-512. Of course, SHA-512 has an even longer value, 64 bytes, but with
just one or at most a few ZONEMD RRs at the zone apex, that does not seem
to be a problem. Of my security comments, I rate adding a 2nd hash
algorithm as the most important. It could be that the 2nd algorithm would
be a SHOULD rather than a MUST. And, if a second algorithm is added, I
think SHA-512 would be the easiest for implementers.

> > to make much difference seems very unlikely.

<de> Response above.

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

<de> I went and read that thread. I agree that the text removed was kind of
complex. I was just worried that the text in Section 4 too strongly implied
that an implementation must accept a zone if a ZONEMD validates. True, it
does have text about "supporting" the Scheme and Hash Algorithm but
conceivable you could support a Scheme and a Hash Algorithm but have a
policy against accepting a ZONEMD RR that combined them and in any case I
suspect the draft is using "supported" in the sense of "implemented". I'd
be happy with adding just one sentence in Section 4 something like "The
verifier MAY ignore a ZONEMD if the Scheme and Hash Algorithm violates
local policy."
...

> smaller that shouldn't be a problem.

 <de> OK. It isn't gigantic or anything, just a bit larger than the 3 or 4
or so values I typically see.

...
> their Implementation Status sections, sometimes as an appendix?

<de> OK... I think that if retained it would be much better as an appendix.

 ...

> Thank you, we did find it very helpful.

<de> You're welcome.

<de> Donald

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 21 Sep 2020 17:31:34 +0000

Donald,

Thanks again for this draft review and feedback.  After discussions among the coauthors we have made the further changes that you suggest.  Namely:

 - minimum digest length of 12 octets
 - added SHA512 as algorithm 2
 - local policy allows some schemes / algorithms to be ignored
 - implementation status moved to an appendix

I think there are no more outstanding issues.  I will be posting an updated revision of the draft shortly.

DW

> On Sep 15, 2020, at 7:34 PM, Donald Eastlake <[email-masked]> wrote:
> 
> Hi Duane,
> 
> On Tue, Sep 15, 2020 at 11:38 AM Wessels, Duane <[email-masked]> wrote:
> <de> Well, it looked to me like the draft already had a minimum Digest field, namely one octet, since it said the Digest Field couldn't be empty. As I recall, the digest didn't say what to do if the Digest field was zero length but I presume it would mean that the ZONEMD RR was malformed and thus could not be used to validate a zone. Seems like the minimum length would apply to private use algorithms also. See Section 5.2.2.1 of https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc2845bis-09
> 
> <de> I agree it is a significant change in the draft. But, as I say, if you have SHA-384 you have 99+% of the crypto code you need for SHA-384 and SHA-512. Of course, SHA-512 has an even longer value, 64 bytes, but with just one or at most a few ZONEMD RRs at the zone apex, that does not seem to be a problem. Of my security comments, I rate adding a 2nd hash algorithm as the most important. It could be that the 2nd algorithm would be a SHOULD rather than a MUST. And, if a second algorithm is added, I think SHA-512 would be the easiest for implementers.
>  
> <de> I went and read that thread. I agree that the text removed was kind of complex. I was just worried that the text in Section 4 too strongly implied that an implementation must accept a zone if a ZONEMD validates. True, it does have text about "supporting" the Scheme and Hash Algorithm but conceivable you could support a Scheme and a Hash Algorithm but have a policy against accepting a ZONEMD RR that combined them and in any case I suspect the draft is using "supported" in the sense of "implemented". I'd be happy with adding just one sentence in Section 4 something like "The verifier MAY ignore a ZONEMD if the Scheme and Hash Algorithm violates local policy." 
> ... 
>  <de> OK. It isn't gigantic or anything, just a bit larger than the 3 or 4 or so values I typically see.
> 
> ...

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 21 Sep 2020 16:35:43 -0400

Hi Duane,

Thanks, looks good to me. I'll check the draft when it comes out.

Donald

On Mon, Sep 21, 2020 at 1:31 PM Wessels, Duane <[email-masked]>
wrote:

> Donald,
>
> Thanks again for this draft review and feedback.  After discussions among
> the coauthors we have made the further changes that you suggest.  Namely:
>
> > <de> I agree it is a significant change in the draft. But, as I say, if
> you have SHA-384 you have 99+% of the crypto code you need for SHA-384 and
> > <de> I went and read that thread. I agree that the text removed was kind
> of complex. I was just worried that the text in Section 4 too strongly
> implied that an implementation must accept a zone if a ZONEMD validates.
> True, it does have text about "supporting" the Scheme and Hash Algorithm
> but conceivable you could support a Scheme and a Hash Algorithm but have a