Subject: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Thu, 08 Oct 2020 04:18:21 -0700

Robert Wilton has entered the following ballot position for
draft-ietf-dnsop-dns-zone-digest-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-zone-digest/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank for you this document.  I found it interesting and it looks useful.

I have a few comments that may improve this document for you to please consider:

   Herein, SHA384 [RFC6234], with value 1, is the only standardized Hash
   Algorithm defined for ZONEMD records that MUST be implemented.  When
   SHA384 is used, the size of the Digest field is 48 octets.  The
   result of the SHA384 digest algorithm MUST NOT be truncated, and the
   entire 48 octet digest is published in the ZONEMD record.

   SHA512 [RFC6234], with Hash Algorithm value 2, is also defined for
   ZONEMD records, and SHOULD be implemented.  When SHA512 is used, the
   size of the Digest field is 64 octets.  The result of the SHA512
   digest algorithm MUST NOT be truncated, and the entire 64 octet
   digest is published in the ZONEMD record.

For consistency, perhaps change "with value 1" to "with Hash Algorithm value 1"?

    2.2.4.  The Digest Field

       The Digest field MUST NOT be shorter than 12 octets.  Digests for the
       SHA384 and SHA512 hash algorithms specified herein are never
       truncated.  Digests for future hash algorithms MAY be truncated, but
       MUST NOT be truncated to a length that results in less than 96-bits
       (12 octets) of equivalent strength.

When I read this, I wonder why the limit of 12 bytes was chosen.  Possibly a
sentence that justifies why this value was chosen might be useful, noting that
the two suggested algorithms have significantly longer digests.

    2.  The ZONEMD Resource Record

       It is
       RECOMMENDED that a zone include only one ZONEMD RR, unless the zone
       publisher is in the process of transitioning to a new Scheme or Hash
       Algorithm.

I'm not quite sure how well this fits with sections 2.2.3 restriction that
SHA384 MUST be implemented, and SHA512 SHOULD be implemented.   As a recipient
of the zone info I understand that I would need to implement both, but as a
sender am I allowed to only send SHA512, or both, or must I always send SHA384?

    3.1.  Add ZONEMD Placeholder

       In preparation for calculating the zone digest, any existing ZONEMD
       records (and covering RRSIGs) at the zone apex are first deleted.

I think that this places a requirement that all zone digests must be
constructed at the same time.  I suggest at least changing "zone digest" to
"zone digest(s)", but it might also be worth adding a sentence to highlight
that.

I was also left wondering whether it is strictly required that the zone digests
must be deleted, or just that placeholder zone digests must be used in their
place during the calculation.  E.g. what happens if a request is received to
fetch the ZONEMD record at the same time that it is being reconstructed?

4.  Verifying Zone Digest

   5.  Loop over all apex ZONEMD RRs and perform the following steps:

   ...

My, perhaps mistaken, interpretation of these error reporting instructions in
this loop is that they really assume only a single ZONEMD RR.  I.e., I wouldn't
expect the recipient to generate/return these errors if there were two ZONEMD
RR's and only one scheme/algorithm was was supported.  Yes, there is some text
at the beginning of the entire algorithm that suggests what to do here, but
further guidance here may also be helpful.  E.g. what does the server return if
there are two ZONEMD records and neither of them are acceptable for different
reasons?  I'm presuming, perhaps incorrectly, that only a single error
can/should be returned.

Regards,
Rob

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 8 Oct 2020 19:47:29 -0400

> draft-ietf-dnsop-dns-zone-digest-12: No Objection

To me, the purpose of the limit is to establish a minimum strength
against brute force attacks. Of course, the hash algorithm also has to
be strong but the length of the Digest field puts a sharp limit on the
strength of a ZONEMD.

Note that for the same reason there is a similar provision from 2006
in RFC 4635, Section 3.1, point 4, which sets a minimum size of 10
bytes for the hashes that appear in TSIG RRs.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 9 Oct 2020 09:23:07 +0000

Hi Donald,

> -----Original Message-----
> From: Donald Eastlake <[email-masked]>
> Sent: 09 October 2020 00:47
> To: Rob Wilton (rwilton) <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked];
> Tim Wicinski <[email-masked]>; <[email-masked]> <[email-masked]>;
> [email-masked]
> Subject: Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-
> zone-digest-12: (with COMMENT)
> 
[RW] 

I absolutely agree on specifying a minimum value.  My question is how was the minimum length of "12 bytes" chosen?  Is there some analysis performed that indicates that this is the right minimal value, or is this just a "12 bytes sounds like enough"?

Regards,
Rob

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 9 Oct 2020 18:36:28 +0000

> On Oct 8, 2020, at 4:18 AM, Robert Wilton via Datatracker <[email-masked]> wrote:
> 

Done.

> the two suggested algorithms have significantly longer digests.

I know there has been some followup on this with Donald.  In our earlier
conversations with him he wrote "96 bits seems to be a common minimum
length for disgests in the IETF although perhaps I have that impression
due to the common case of SHA-1 truncated to 96 bits."

> sender am I allowed to only send SHA512, or both, or must I always send SHA384?

As sender (publisher) you are allowed to publish whatever you want.

The purpose of the recommendation above is to hopefully avoid the situation
where multiple records are published (with both types) on an ongoing basis.
That is something we observe with DS records quite often.  For example,
750 TLDs today publish both SHA1 and SHA256 digest types as DS records in
the root zone.  This new paragraph has been added to the security
considerations:

6.2.  Use of Multiple ZONEMD Hash Algorithms

   When a zone publishes multiple ZONEMD RRs, the overall security is
   only as good as the weakest hash algorithm in use.  For this reason,
   Section 2 recommends only publishing multiple ZONEMD RRs when
   transitioning to a new scheme or hash algorithm.  Once the transition
   is complete, the old scheme or hash algorithm should be removed from
   the ZONEMD RRSet.

> "zone digest(s)", but it might also be worth adding a sentence to highlight

I've changed it to "zone digest(s)" as you suggest.

Strictly speaking, there is not a requirement that all digests must be created
at the same time (in parallel).  

The reason for the placeholder is explained in the next paragraph, which is to
ensure correct NSEC/NSEC3 records when the zone is signed with DNSSEC. 

> fetch the ZONEMD record at the same time that it is being reconstructed?

It is not strictly required to delete any existing digest first.  The ZONEMD records
are not included in the digest calculation.

To address your questions around this, I suggest adding this text to section 3,
before section 3.1:

3.  Calculating the Digest

   The algorithm described in this section is designed for the common
   case of offline DNSSEC signing.  Slight deviations may be permitted
   or necessary in other situations, such as with unsigned zones or
   online DNSSEC signing.  Implementations that deviate from the
   described algorithm are advised to ensure that identical ZONEMD RRs,
   signatures, and dential-of-existence records are produced.

> reasons?  I'm presuming, perhaps incorrectly, that only a single error

Ben raised a similar point about this section, namely that it could result
in a lot of diagnostic output.  

Do you think it would be better remove those "SHOULD report" from each individual
step and instead have a paragraph at the end that says the verifier SHOULD report
the result of its verification and leave it at that?

> Rob

Thanks for the review and comments!

DW

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 9 Oct 2020 15:08:35 -0400

On Fri, Oct 9, 2020, 2:36 PM Wessels, Duane <dwessels=
[email-masked]> wrote:

>    only as good as the weakest hash algorithm in use.

Why not require recipients to verify all digests with recognized algorithms?

  For this reason,
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 9 Oct 2020 20:33:10 +0000

> On Oct 9, 2020, at 12:08 PM, Ben Schwartz <[email-masked]> wrote:
> 
> 

That text stating that one is sufficient was based on a conversation in the working group that started here:

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

DW

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 9 Oct 2020 23:10:14 -0400

Hi Rob,

I'm not aware of any precise analysis supporting the 12 byte minimum
size but I believe it is reasonable and in line with the lower end of
the range of hash sizes typically standardized by the IETF these days.

Thanks,
Donald

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 9 Oct 2020 20:25:17 -0700

Hi Rob,

One can do a bit of semi-generic analysis here to help motivate 12 bytes as
being a tolerable choice (one could make some argument for 32 being the
right length to actually use, but the protocol-mandated floor does not
necessarilly need to be the "full protection" value as there can be
trade-offs in play.

There's two general classes of attack to consider: when an external
attacker takes an existing ZONEMD and tries to modify the associated zone,
or when the zone provider is the malicious entity that wants to provide
different content to different people but give them the same digest value
so that the cursory examination indicates the two different zones are
identical.  (The second one is going to be fairly contrived most of the
time, and may not be in the practical threat model for most people.)  In
the former case the cryptographic property in play is second-preimage
resistance which, in the absence of a quantum computer, scales as the
bitlength of the output, so 12 bytes of digest means that for a good hash
function the attacker has to put in a work factor of roughly 2**96, which
is a substantial burden.  The cryptographic property in play for the second
case is regular collision resistance, which scales as the square root of
the preimage problem due to the birthday paradox.

A work factor of 2**48 is feasible but nontrivial, so 12 bytes poses some
burden for both classes of attack and a substantial burden for the riskier
attack.  To me, that seems like a reasonable tradeoff for the bare minimum
allowed by the protocol, though of course opinions can differ.

-Ben

---

From: "John Levine" <[email-masked]>
Date: 10 Oct 2020 11:34:11 -0400

In article <[email-masked]> you write:
>different content to different people but give them the same digest value ...
 
I think there's a third threat, a transcription error due to
transmission error or other kinds of bitrot. I send zone files between
my DNS servers over ssh, so the chances of an external attack are low,
but particularly as zone files continue to grow, the protection of the
TCP checksum is less effective. On my rather small DNS setup I have a
71MB zone and I don't think that's unusual. In many, probably most,
cases a bit flip or two would produce DNS data that is still valid but
wrong, e.g., change the address in AAAA or the characters in a name
anywhere.

That's why there are situations where a zone digest can be useful
even without a DNSSEC validation chain.

R's,
John

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 11 Oct 2020 21:07:07 -0700

> wrong, e.g., change the address in AAAA or the characters in a name

At risk of being overly glib, "Murphy is often a very effective attacker".
That is, the analysis for this decomposes into a subset of the first case I
listed.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 11 Oct 2020 21:14:48 -0700

> > On Oct 8, 2020, at 4:18 AM, Robert Wilton via Datatracker <[email-masked]> wrote:
[...]
>    is complete, the old scheme or hash algorithm should be removed from

While I'm happy to see this statement made, I do want to note that the
actual properties here have some complex interplay, and "only as good as
the weakest hash algorithm in use" may only be strictly true in certain
scennarios.  (So, in the general case, it is a true statement, but there
may be certain cases in which it does not hold.)  In particular, since
DNSSEC signs the whole RRset, it does not seem like it is possible (without
some other attack) to modify things so that the ZONEMD with a different
hash algorithm is not visible while retaining the RRSIG.  And if you have
a signed zone with a weak hash for ZONEMD, producing a different zone that
collides the ZONEMD will probably not retain all the RRSIGS on the other
records (though could plausibly retain most of them).  So, it's
complicated, but I'm not sure that we really need to get into the specifics
in this document.  Personally, I'm fine keeping this text as-is, but I did
want to note the subtlety involved.

-Ben

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 12 Oct 2020 12:23:25 +0000

Hi Ben,

Thank you for the explanation and justification.

I personally find this sort of explanation really useful.  I do wonder whether this sort of material might make a useful informational RFC at some point ... although of course everyone is very busy.

But anyway, I think that we can regard my original comment as resolved.

Regards,
Rob

> From: Benjamin Kaduk <[email-masked]>
> Sent: 10 October 2020 04:25
> Cc: [email-masked]; Tim Wicinski
> <[email-masked]>; [email-masked]; <[email-masked]>
> <[email-masked]>; The IESG <[email-masked]>; Donald Eastlake
> <[email-masked]>; Roman Danyliw <[email-masked]>
> > > > >        The Digest field MUST NOT be shorter than 12 octets.
> Digests for
> > > > the
> > > > >        truncated.  Digests for future hash algorithms MAY be
> truncated,
> > > > but
> > > > >        MUST NOT be truncated to a length that results in less than
> 96-
> > > > bits
> > > I absolutely agree on specifying a minimum value.  My question is how
> was the minimum length of "12 bytes" chosen?  Is there some analysis
> performed that indicates that this is the right minimal value, or is this
> just a "12 bytes sounds like enough"?
> > >
> > > Regards,
> > > Rob
> > >
> > >
> > > >

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 12 Oct 2020 15:56:14 +0000

Hi Duane,

Please see inline.

> From: iesg <[email-masked]> On Behalf Of Wessels, Duane
> Sent: 09 October 2020 19:36
> <[email-masked]>; [email-masked]; [email-masked]; The IESG
> <[email-masked]>
> Subject: Re: Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-
> digest-12: (with COMMENT)
> 
> 
> 
[RW] 

As per my comment to Ben, I think that you can regard this one as closed.

[RW] 

Okay, taken in conjunction with 2.2.3 that didn't seem clear to me.  My reading is that the sender SHOULD only send one, and [everyone] MUST support SHA384, effectively implying that is SHA384 that MUST be sent ...  Perhaps the RFC 2119 language in section 2.2.3 needs to be restricted to receivers processing ZONEMD records?  ... or some other way to convey the difference in requirements on algorithm implementation between senders and receivers.

[RW] 

Yes, I think that would help clarify.

[RW] 

Yes, I think that would be better.

Regards,
Rob

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 14 Oct 2020 12:35:01 +0000

> On Oct 12, 2020, at 8:56 AM, Rob Wilton (rwilton) <rwilton=[email-masked]> wrote:
> 
> 
> 
>> 
>>> 

Hi Rob,

To address this, here is what we suggest:

In sections 2.2.2 and 2.2.3, rather than saying "MUST/SHOULD be implemented" we'll say "MUST/SHOULD be supported by implementations."

The paragraph about multiple digests at the start of section 2 will be moved to this new section 2.5:

2.5.  Including ZONEMD RRs in a Zone

   The zone operator chooses an appropriate hash algorithm and scheme,
   and includes the calculated zone digest in the apex ZONEMD RRset.
   The zone operator MAY choose any of the defined hash algorithms and
   schemes, including the private use code points.

   The ZONEMD RRSet MAY contain multiple records to support algorithm
   agility [RFC7696].  [RFC Editor: change that to BCP 201] When
   multiple ZONEMD RRs are present, each MUST specify a unique Scheme
   and Hash Algorithm tuple.  It is RECOMMENDED that a zone include only
   one ZONEMD RR, unless the zone operator is in the process of
   transitioning to a new scheme or hash algorithm.

DW

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 15 Oct 2020 10:38:50 +0000

Hi Duane,

That looks good.  Thanks for accommodating.

Regards,
Rob

> Sent: 14 October 2020 13:35
> To: Rob Wilton (rwilton) <rwilton=[email-masked]>
> > On Oct 12, 2020, at 8:56 AM, Rob Wilton (rwilton)
> <rwilton=[email-masked]> wrote:
> >
> >
> >
> >>
> >>>
> >>> sender am I allowed to only send SHA512, or both, or must I always
> send
> >> SHA384?
> >>
> > Okay, taken in conjunction with 2.2.3 that didn't seem clear to me.  My
> reading is that the sender SHOULD only send one, and [everyone] MUST
> support SHA384, effectively implying that is SHA384 that MUST be sent ...
> Perhaps the RFC 2119 language in section 2.2.3 needs to be restricted to
> receivers processing ZONEMD records?  ... or some other way to convey the
> difference in requirements on algorithm implementation between senders and
> receivers.
> >
> 
> 
> Hi Rob,
> 
> In sections 2.2.2 and 2.2.3, rather than saying "MUST/SHOULD be
> implemented" we'll say "MUST/SHOULD be supported by implementations."
>

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 15 Oct 2020 17:02:16 +0000

Dear IESG,

I believe all outstanding comments and concerns have now been addressed, so revision -14 has been posted.  

DW

> On Oct 15, 2020, at 3:38 AM, Rob Wilton (rwilton) <[email-masked]> wrote:
> 
> Hi Duane,
>