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

From: Warren Kumari <[email-masked]>
Date: Tue, 21 Jan 2020 12:10:03 -0500

[ - 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 <[email-masked]> 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
> [email-masked]
> 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

---

From: Tony Finch <[email-masked]>
Date: Tue, 21 Jan 2020 17:31:49 +0000

> SHA-256 might be in order.

Yes.

> There is already some text:

For context, the preceding paragraph says:

   The only message digest algorithm specified in the first version of
   these specifications [RFC2845] was "HMAC-MD5" (see [RFC1321],
   [RFC2104]).  Although a review of its security [RFC6151] concluded
   that "it may not be urgent to remove HMAC-MD5 from the existing
   protocols", with the availability of more secure alternatives the
   opportunity has been taken to make the implementation of this
   algorithm optional.

>    The use of SHA-1 [FIPS180-4], [RFC3174], (which is a 160-bit hash as
>    shorter hashes.

I think the quoted paragraph should say something like:

   [RFC4635] added mandatory support in TSIG for SHA-1 [FIPS180-4],
   [RFC3174]. 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].

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
German Bight: West veering northwest 4 or 5. Slight or moderate. Occasional
drizzle. Good, occasionally poor.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 21 Jan 2020 15:46:41 -0500

>    hmac-sha256 or other SHA-2 digest algorithms [FIPS180-4], [RFC3874],

Oooh. I like it - that seems to address both my, and (presumably!)
Magnus' concerns -- anyone object / have any additions?

W

---

From: Warren Kumari <[email-masked]>
Date: Thu, 23 Jan 2020 19:29:40 -0500

Great, I'll take the silence as wide endorsement, and ask that the
authors update the document with this text (or something similar...) -
I'll then start IESG Eval.

Thanks again to Tony for the text, and Magnus for the review,
W

---

From: Tony Finch <[email-masked]>
Date: Fri, 24 Jan 2020 14:31:59 +0000

> I'll then start IESG Eval.

PS. wrt "collisions", might be worth adding informative references to
https://sites.google.com/site/itstheshappening/
https://shattered.io/
https://sha-mbles.github.io/

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Lough Foyle to Carlingford Lough: South or southwest 3 or 4, increasing 5 or 6
later. Smooth or slight at first in southeast, otherwise slight or moderate,
occasionally rough in north. Occasional rain or drizzle, mainly in north.
Moderate or good, occasionally poor in north.