Subject: I-D Action:draft-ietf-dnsext-tsig-md5-deprecated-00.txt

From: [email-masked]
Date: Mon, 30 Jun 2008 02:30:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title           : Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records
	Author(s)       : F. Dupont
	Filename        : draft-ietf-dnsext-tsig-md5-deprecated-00.txt
	Pages           : 6
	Date            : 2008-06-30

The main goal of this document is to deprecate the use of HMAC-MD5 as
an algorithm for the TSIG (secret key transaction authentication)
resource record in the DNS (domain name system).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tsig-md5-deprecated-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 30 Jun 2008 08:56:16 -0700

Greetings again. The logic in this document is kind of a mess. It 
says, in essence:

a) MD5 turns out to be weaker than expected for a hash

b) therefore it should be deprecated and HMAC-SHA1 be mandatory

The first statement is certainly true, but irrelevant, because TSIG 
uses HMAC-MD5, not MD5. As the draft admits, there are no known 
attacks on HMAC-MD5. To the best of my knowledge, there have been no 
papers published even hinting at it.

The second statement is short-sighted. The document talks about the 
desire to have algorithms that can be used in systems that are 
validated with FIPS 140 for NIST in the US. However, NIST has already 
said that SHA-1 will be deprecated in about 2.5 years; see 
<http://csrc.nist.gov/groups/ST/hash/statement.html>. So making SHA-1 
mandatory based on wanting to use FIPS algorithms is also not a good 
idea. Getting rid of TSIG-HMAC-MD5 for NIST-related reasons would 
also require us to get rid of TSIG-HMAC-SHA1, either now or in 2.5 
years from now.

If the only reason for this draft to exist is to deprecate 
TSIG-HMAC-MD5, then it seems like vast overkill. Instead, a better 
idea is a simple one-page draft that takes TSIG-HMAC-MD5 from 
mandatory to optional. That draft doesn't need any questionable 
cryptography or discussion of NIST.

--Paul Hoffman, Director
--VPN Consortium

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Scott Rose <[email-masked]>
Date: Mon, 30 Jun 2008 13:07:07 -0400

Paul Hoffman wrote:
> Greetings again. The logic in this document is kind of a mess. It says, 
> in essence:
> 
> The first statement is certainly true, but irrelevant, because TSIG uses 
> HMAC-MD5, not MD5. As the draft admits, there are no known attacks on 
> HMAC-MD5. To the best of my knowledge, there have been no papers 
> published even hinting at it.
> 
> desire to have algorithms that can be used in systems that are validated 
> with FIPS 140 for NIST in the US. However, NIST has already said that 
> SHA-1 will be deprecated in about 2.5 years; see 
> idea. Getting rid of TSIG-HMAC-MD5 for NIST-related reasons would also 
> require us to get rid of TSIG-HMAC-SHA1, either now or in 2.5 years from 
> now.
> 
SHA-1 is to be deprecated by 2010, but that doesn't include HMAC-SHA1, 
which can continue beyond 2010 if used with an appropriately long secret 
string.  I don't know if that extends back to HMA-MD5, but I do know 
HMAC-SHA1 is still allowed for use within the USG after 2010 or until a 
known attack is discovered.

> TSIG-HMAC-MD5, then it seems like vast overkill. Instead, a better idea 
> is a simple one-page draft that takes TSIG-HMAC-MD5 from mandatory to 
> optional. That draft doesn't need any questionable cryptography or 
> discussion of NIST.
> 
I agree with the last part.  I could also live with moving HMAC-MD5 to 
optional.  It is up to the parties involved to decide with algorithm to 
use anyway.

Scott

-- 
----------------------------------------
Scott Rose            Computer Scientist
NIST
ph: +1 301-975-8439
[email-masked]

http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
-----------------------------------------