Re: [DNSOP] [secdir] Secdir review of draft-ietf-dnsop-rfc2845bis-06

[ - 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 <magnusn@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
> secdir@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