Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-tsig-md5-deprecated-02.txt

From: Francis Dupont <[email-masked]>
Date: Mon, 04 May 2009 16:16:00 +0200

In your previous mail you wrote:

   >Abstract
   
=> changed goal into purpose and added something about MD5 and TKEY.
   
   >1.  Introduction
   "lower than expected" -> "weaker than expected"?
   (RFC 4635 uses "stronger")
   
   >    1.  Mark HMAC-MD5.SIG-ALG.REG.INT as optional in the TSIG algorithm
   >        name registry managed by the IANA under the IETF Review Policy
   >        [RFC5226]
   
   Can we mark it "historic" instead of "optional?"  Or even "deprecated?"
   
=> about this (and similar other comments): this point was proposed but
was rejected by rough consensus. The two problems are:
 - there is no deprecated or historic requirement keywords
 - there is no crypto reason to ban HMAC-MD5

   >5.  Availability Considerations
   
   And SHA1 "is [eventually?} likely to suffer" - any time soon?  This 
   doc title is about HMAC-MD5, not SHA1.
   
=> SHA1 end of life is planned in 2010 (cf NIST, BTW 2010 is next year)
so even there is nothing against HMAC-SHA1 the same availability problem
could occur so between the two remaining "mandatory to support" algos
HMAC-SHA256 is the best candidate.
BTW I agree it is far too soon to say more about SHA1.

   >6.  Security Considerations
   
   That's okay for HMAC-MD5 if there is a reference to a statement it is 
   obsolete,

=> it is not obsolete, it is just no longer available. And I can't add
a cryto reference about a HMAC-MD5 weakness (just because there is none),
MD5 itself being out of context. So as it is written "this document
does not assume anything about the cryptographic security of different
hash algorithms."

   I'd drop any change to SHA1 for now

=> no problem: there is no change to SHA1.

   and add pointers to HMAC analysis to support this assertion.
   
=> which assertion? I've carefully avoided any assertion about
cryptography in the security considerations.

Thanks

[email-masked]

PS: the whole document is about how to allow both "certified" and "compliant"
in the "use a certified cryptography module in a compliant TSIG
implementation" where:
 - "certified" means for instance FIPS 140-2 certified
 - "compliant" means all mandatory to support algos, in particular HMAC-MD5,
  are supported
 - "use" means more than usual because of the certified (cf FIPS 140-2
  Implementation Guidance section G.5 guidelines)
 - "TSIG implementation" is of course any DNS tool which implements TSIG
so it is really an availability problem...

--
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: Thu, 07 May 2009 12:31:16 -0400

> BTW I agree it is far too soon to say more about SHA1.
Minor point-
SHA-1 will no longer be approved for use (within the US Government only)
with digital signing.  HMAC-SHA1 is still acceptable if the secret
string used is a sufficient length and random (i.e. generated using an
approved random number generation technology).

Given the recent news about SHA-1, that might change.

Scott

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

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 7 May 2009 10:21:15 -0700

>approved random number generation technology).

This is not a minor point, particularly with respect to the draft.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Thu, 07 May 2009 14:18:49 -0700

Scott and all,

SHA-1 was broken/compermised over two years ago now, and
NIST should have immediately discontinued it approved use at
that time.  This said, I for one am relieved that NIST has belatedly
decided that SHA-1 is no longer approved for Govt. use.

  HMAC -SHA1 also should be discontinued for Govt. use ASAP.
It appears that there have been some succesful breakage here as well.
Key lengths of 512k or larger may still be safe for use however. Frankly
I would if I were the USG, get away from HMAC all toghther ASAP
as well.  But that's your all's call.

  Basically we need to stay 2 steps ahead of the black hat Crackers.

> Given the recent news about SHA-1, that might change.

Regards,

Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln
"YES WE CAN!"  Barack ( Berry ) Obama

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
[email-masked]
My Phone: 214-244-4827

---

From: Francis Dupont <[email-masked]>
Date: Fri, 08 May 2009 14:35:37 +0200

Minor point-

=> note I agree it is minor (we don't talk about RSA-SHA1 here, i.e.,
the I-D is not draft-ietf-dnsext-dnssec-rsasha256).

   
=> this is an example of what suggests SHA-1 could become unavailable
(a drastic way to enforce no misuse of SHA-1 is just to not provide it).

BTW the proposed requirements (HMAC-SHA1 and HMAC-SHA256 mandatory to
support, HMAC-SHA257 recommended to use) are still good. Perhaps one
day we'll have to make HMAC-SHA1 support only optional but it is clearly
too soon.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Fri, 08 May 2009 14:46:48 +0200

=> note the draft here is *not* draft-ietf-dnsext-dnssec-rsasha256 but
draft-ietf-dnsext-tsig-md5-deprecated.
I can't see why it is not a minor point:
 - SHA-1 is still approved for HMAC-SHA1 and key generation (i.e., TKEY)
 - so one can reasonably expect to get it in US certified crypto today
  (i.e., the use of certified crypto and RFC compliance are still
   compatible)
 - so "if the secret..." is a constraint on use which is compatible too
 - the recommendation for HMAC-SHA256 seems to be compatible too
  (even a "if a secret..." constraint is very likely to be applied too).
So this "minor point" only increases the opportunity to update TSIG and
TKEY algo requirement levels.

Regards

PS: of course the situation is different for
draft-ietf-dnsext-dnssec-rsasha256: to wait becomes less and less
acceptable.

---

From: Scott Rose <[email-masked]>
Date: Fri, 08 May 2009 08:49:55 -0400

Yes - I agree with the requirements in the current draft.  I would like to
see as much algorithm agility in implementations as possible, but that's
beyond the scope of this draft.

Currently, there is some growing concern about hmac-sha1 from the crypto
folks here, so it's a good idea to have hmac-sha256 implemented as well to
make transition easier without having to wait for upgrades.

Scott

> [email-masked]

===================================
Scott Rose
NIST
[email-masked]
ph: +1 301-975-8439
http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
===================================

---

From: Francis Dupont <[email-masked]>
Date: Fri, 08 May 2009 15:15:07 +0200

=> as I am not an US citizen I don't comment (:-).

=> I am interested by a reference to a serious scientific paper about
this point.

   Key lengths of 512k or larger may still be safe for use however.

=> as far as I know a key larger than the block size doesn't bring
more security to HMAC.

PS: if there are some cryptographers in the room, I look for a short
and readable (for standard human beings) explanation about the reasons
why a key smaller than the half of the digest size (i.e., 80 for SHA-1,
128 for SHA-256) is not good, and a key larger than the digest size does
not bring more (i.e., with a digest size S, the acceptable range should be
[S/2, infinity) and default S for the key size).