[DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-rfc2845bis-07: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-dnsop-rfc2845bis-07: 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-rfc2845bis/



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

** Section 1.3.  Per “In 2017, two nameservers  strictly following that
document (and the related [RFC4635]) were discovered to have security problems
related to this feature”, consider providing a reference to the published
vulnerabilities (i.e., CVE-2017-3142 and CVE-2017-3143)

** Section 6.  Per “SHA-1 collisions have been demonstrated so the MD5 security
considerations apply to SHA-1 in a similar manner.  Although support for
hmac-sha1 in TSIG is still mandatory for compatibility reasons, existing uses
should be replaced with hmac-sha256 or other SHA-2 digest algorithms
[FIPS180-4], [RFC3874], [RFC6234].

-- It’s worth repeating those MD5 security considerations here

-- (from Magnus Nystrom’s SECDIR review, thanks Magnus!) it’s worth including
references to the recent SHA-1 cryptoanalysis provided in the SECDIR review

-- The SHA-2 family should be a normative SHOULD (or RECOMMENDED).

** Section 10.  Per “For all of the message authentication code algorithms
listed in this document, those producing longer values are believed to be
stronger”, as noted in Magnus’s SECDIR review, this could be misconstrued as
the algorithm choice not the digest length provides the security.  Recommend
rephrasing (or making some statement

** Editorial
-- Section 4.3.2.  Per “When verifying an incoming message, this is the message
after the TSIG RR and been removed and the ARCOUNT field has been
decremented.”, this sentence doesn’t parse (is missing a word).

-- Section 4.3.2.  Per “A whole and complete DNS message in wire format.”, this
isn’t a sentence.