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

[Donald Eastlake <[e-mail]>]

You're welcome.

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

On Wed, Oct 7, 2020 at 10:48 PM Benjamin Kaduk <[e-mail]> wrote:
>
> Donald, thanks for the review -- it's always good to see the core
> agility and algorithm-strength questions well in hand.
>
> Duane, thanks for the updates -- as you saw, my discuss points were pretty
> boring process/mechanical-type stuff, and I'll respond to you shortly.
>
> -Ben
>
> On Mon, Sep 21, 2020 at 04:35:43PM -0400, Donald Eastlake wrote:
> > Hi Duane,
> >
> > Thanks, looks good to me. I'll check the draft when it comes out.
> >
> > Donald
> > ===============================
> >  Donald E. Eastlake 3rd   [phone] (cell)
> >  2386 Panoramic Circle, Apopka, FL 32703 USA
> >  [e-mail]
> >
> >
> > On Mon, Sep 21, 2020 at 1:31 PM Wessels, Duane <[e-mail]>
> > 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:
> > >
> > >  - 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 <[e-mail]> wrote:
> > > >
> > > > 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 <[e-mail]>
> > > 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
> > > > - 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:
> > > > >
> > > > ...
> > > > >
> > > > > 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).
> > > >
> > > > <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
> > > >
> > > > > 3) SHA384 / algorithm agility
> > > > > -- here are some thoughts/comments on SHA384 and algorithm agility:
> > > > ...
> > > > >
> > > > > 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?
> > > >
> > > > <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.
> > > >
> > > > > 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.
> > > >
> > > > <de> Response 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/
> > > >
> > > > <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."
> > > > ...
> > > > > 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.
> > > >
> > > >  <de> OK. It isn't gigantic or anything, just a bit larger than the 3 or
> > > 4 or so values I typically see.
> > > >
> > > > ...
> > > > > 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?
> > > >
> > > > <de> OK... I think that if retained it would be much better as an
> > > appendix.
> > > >
> > > >  ...
> > > > > 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.
> > > >
> > > > <de> You're welcome.
> > > >
> > > > <de> Donald
> > > > ===============================
> > > >  Donald E. Eastlake 3rd   [phone] (cell)
> > > >  2386 Panoramic Circle, Apopka, FL 32703 USA
> > > >  [e-mail]
> > >
> > >
>