[ - secdir for clutter, +DNSOP ] Hello DNSOPers,
I'm looking for some advice / discussion... Below is the security directorate review of https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc2845bis/ (posted to the secdir list) -- normally I'd just start IESG Eval and let the security ADs review and comment there, but this seems (to me) like it may deserve more discussion, so I'm posting this here, and will point the security ADs at it (and ask if there is anyone else who should be reviewing too). This -bis was intended to be a relatively simple patch (see Section 10.1, 10.2), and providing stronger advice against using SHA-1 is a (somewhat) larger change. I don't think that it is realistic to deprecate SHA-1 in TSIG for the foreseeable future, but stronger recommendations about moving to SHA-256 might be in order. There is already some text: "The use of SHA-1 [FIPS180-4], [RFC3174], (which is a 160-bit hash as compared to the 128 bits for MD5), and additional hash algorithms in the SHA family [FIPS180-4], [RFC3874], [RFC6234] with 224, 256, 384, and 512 bits may be preferred in some cases. This is because increasingly successful cryptanalytic attacks are being made on the shorter hashes." -- perhaps all that would need to be done would be to make that much stronger? I'm sure this isn't a "the sky is falling", but Magnus does raise a good point, and I think that this is a good hygine opportunity... Thoughts? W On Mon, Jan 20, 2020 at 12:37 AM Magnus Nyström <magn...@gmail.com> wrote: > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments. > > This document defines a mechanism to provide authenticity and integrity of > DNS transactions such as update requests. > > My main comment about this document is that it recommends use, and mandates > support, of HMAC-SHA1, even truncated HMAC-SHA1. In light of recent > cryptanalysis results, e.g., > - https://eprint.iacr.org/2020/014.pdf > - https://www.mitls.org/downloads/transcript-collisions.pdf > it seems to me that an update to RFC 2845 would be better off not to > recommend (or even mandate) use of SHA-1 but rather stronger hash functions > such as SHA-256. > Likewise, the statement "longer [authentication values] are believed to be > stronger" is potentially misleading as it is the strength of the algorithm, > and not the length of its output, that ultimately determines its security. > > Thanks, > -- Magnus > _______________________________________________ > secdir mailing list > sec...@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
