Subject: Re: Adopt draft-dupont-dnsext-tsig-md5-deprecated as WG draft?

From: Francis Dupont <[email-masked]>
Date: Sat, 31 May 2008 15:26:47 +0200

In your previous mail you wrote:

   favoring adoption does not necessarily mean agreeing with the draft, so
   here's my "yes" vote.

=> I am working on a 01 version with editorial fixes (including the
title :-), marked as done after.

   For the reason of making this distinction see the review below:
   
   > Internet-Draft                                                       ISC
   > Intended status: Standards Track                            May 11, 2008
   
   Updates: RFC 2930, RFC 2845, RFC 4635
   
=> done

   >                       Deprecated HMAC MD5 in TSIG
   
   Deprecation of HMAC MD5 in the DNS TSIG and TKEY Resource Records
   
=> done

   >    But it failed to deprecate the HMAC MD5 algorithm.  This document is
   >    targeted to correct this point, in details:
   
   This was a conscious decision at that time, IIRC, wasn't it?
   
=> I don't know, perhaps it was too soon?

   > 2.  IANA Considerations
   
   Move this to the end.
   
=> it is the usual position but is it mandatory? As far as I know
it is only required to have an IANA section... If you can find
another document which is mainly about an IANA registry update,
I propose to use it as an example.

   >    In the registry of TSIG algorithm names, add this comment
   >    "(deprecated, see hmac-sha256)" in the HMAC-MD5.SIG-ALG.REG.INT
   >    entry.
   > 
   >    This is copied from the registry of DNSSEC algorithm numbers which
   >    was updated by [RFC3110].
   
   Strictly procedurally I do not think a comment in the registry is a good
   idea. I'd rather have "this" document added to the references list of
   "HMAC-MD5.SIG-ALG.REG.INT".  RFC 3110 set a precedent, but that registry
   "DNSSEC Algorithm Numbers" already had a "Description" field.
   An implementer would have to consult the requirements levels anyway,
   which are part of neither of these registries. (The second sentence
   above isn't really necessary ;-)
   
=> I proposed to follow strictly the RFC 3110 precedent... The IANA
shall say what they think about this.

   > 3.  Implementation Requirements
   > 
   >    The table of section 3 of [RFC4635] is updated into:
   > 
   >              +-------------------+--------------------------+
   >              | Requirement Level | Algorithm Name           |
   >              +-------------------+--------------------------+
   >              | Optional          | HMAC-MD5.SIG-ALG.REG.INT |
   >              | Optional          | gss-tsig                 |
   >              | Mandatory         | hmac-sha1                |
   >              | Optional          | hmac-sha224              |
   >              | Mandatory         | hmac-sha256              |
   >              | Optional          | hmac-sha384              |
   >              | Optional          | hmac-sha512              |
   >              +-------------------+--------------------------+
   
   There's no reference in RFC 4635 explaining what "Optional" and "Mandatory"
   actually mean, so why not label HMAC-MD5.SIG-ALG.REG.INT "Deprecated" here?
   
=> this is more radical I confess.

   >    Implementations that support TSIG MUST also implement HMAC SHA1 and
   >    HMAC SHA256 and MAY implement gss-tsig and the other algorithms
   >    listed above.
   
   ... MUST implement the algorithms marked Mandatory and MAY implement
   those marked Optional or Deprecated.
   
=> I agree this is clearer.

   > 4.  TKEY keying material derivation
   > 
   >    When the TKEY [RFC2930] uses a Diffie-Hellman exchange, the keying
   >    material is derived from the shared secret and TKEY resource record
   >    data using MD5 [RFC1321] at the end of section 4.1 page 8.
   nit: top of page 9, but better just refer to the section anyway
   
=> oops, you're right: the formula is just on the page break!

   >    This is amended into:
   > 
   >          keying material =
   >               XOR ( DH value, SHA256 ( query data | DH value ) |
   >                               SHA256 ( server data | DH value ) )
   > 
   >    using the same conventions.
   
   A normative reference to RFC 4634 for SHA256 (well, "SHA-256") is
   needed here.

=> I prefer SHA-256 which is the official name but '-' is misleading
in a formula so this is a valid exception IMHO. I note to add a reference.

   What would "amended into" mean? are both algorithms now equally available
   (and distinguished by length)?  Or should SHA256 replace MD5 and if yes,
   wouldn't that be a backwards compatibility issue?
   
=> I don't understand your comment: I proposed to replace MD5 by SHA-256
keeping other things (in particular padding) equal. There is no
compatibility issue other the computed shared secrets will very likely
be different.

   > 5.  Security Considerations
   > 
   >    The use of MD5 and HMAC MD5 is NOT RECOMMENDED in TSIG and related
   >    specifications (i.e., TKEY).
   > 
   >    But SHA-1 seems to be vulnerable too, so the use of at least SHA256
   >    is RECOMMENDED.  As implementations which support TSIG are REQUIRED
   
   This normative language (As .. "REQUIRED") confuses me.
   
=> hum, the wording is bad I agree.

   >    to implement HMAC SHA256, in particular the hmac-sha256 algorithm is
   >    RECOMMENDED for default use in TSIG.
   
   Agree with Ed here that a reason for the deprecation of HMAC-MD5 must be
   given, especially since we've heard that this particular use would not
   be susceptible to the same attacks as MD5 in digital signatures.

=> the reason is MD5 is today considered as too weak for any use.

   >From Francis' earlier message I understand the reason was less cryptographic
   but pragmatic, expecting the removal of md5 from crypto libraries or
   enabling the implementor to remove it from their product.

=> this is more than "expecting": a FIPS 140-2 compliant crypto module
implements only approved algorithms and MD5 is *not* approved.

   And that's why I'm not sure I agree with the draft's recommendation.
   There's also an operational issue with migration from MD5 to SHA-256 through
   SHA-1, when MD5 capable software needs to cooperate with products following
   this advice. One might argue they should at least be able to use SHA-1,
   but then deprecating SHA-1 is around the corner, as well.  Maybe it
   should be explicitly recommended against its use as of now?
   
=> HMAC-SHA256 is marked as mandatory in the RFC 4635 table as using it
should not be a problem, at least no more a problem than HMAC-SHA1.
IMHO it is too soon to deprecate or even change the requirement level
for HMAC-SHA1 but I took benefit of this document to introduce a new(*)
recommendation and jumped directly to SHA-256.
(*) no algo was recommended, MD5 is heavily used only because it is
the first to be specified.

   > 6.  Acknowledgments
   
   >    Olafur Gudmundsson kindly helped in the procedure to deprecate the
   >    MD5 usage in TSIG, i.e., the procedure which gave this memo.
   
   What conspiracy was this? :-)
   
=> you'd like to be in? (:-)

   > 7.  References
   > 
   > 7.1.  Normative References
   
   see above for SHA-256.
   
=> noted.

Thanks

[email-masked]

PS: (previous and these new) changes will be in the 01 version.

--
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: Peter Koch <[email-masked]>
Date: Mon, 9 Jun 2008 23:19:03 +0200

Hi Francis,

thanks for your explanations.

> => I don't know, perhaps it was too soon?

the current wording makes it look like an oversight, where it probably
was intentional.

> I propose to use it as an example.

RFC 5226 says:

      - The IANA Considerations section should summarize all of the IANA
        actions, with pointers to the relevant sections elsewhere in the
        document as appropriate.

But in the end IANA needs to be happy with it ...

> shall say what they think about this.

Well, yes and know - but let's follow your suggestion and ask IANA first.

> => this is more radical I confess.

It's probably more clear. The IANA registry just lists identifiers without
mapping them to, say, a number like for QTYPEs.  So, freeing the old
identifier is not an option to avoid later collisions. So, regarding
the registry, one would somehow convey the message that someone browsing
the list need not bother implementing the outdated algorithm.  The actual
registry, however, doesn't contain any requirements level information,
so adding that in the draft under consideration looks more straight forward
to me.

> in a formula so this is a valid exception IMHO. I note to add a reference.

Good luck for AUTH48 on the '-' ...

> compatibility issue other the computed shared secrets will very likely

This would introduce a hard cut-over, where with TSIG we have a smooth
migration from MD5 through SHA1 to SHA-2*.  If MD5 is instantly deprecated and
replaced by SHA-2, there's no lowest common denominator for two
implementations.  I must admit, though, I don't know how much operational
relevance this really has.

> => the reason is MD5 is today considered as too weak for any use.

That we'd need a reference for!

> implements only approved algorithms and MD5 is *not* approved.

OK, sounds like a reason.

> recommendation and jumped directly to SHA-256.

There's a difference between deprecating its use and deprecating its
implementation.  While SHA1 should continue to be implemented, maybe
the _use_ of SHA-2 could be recommended (if that makes sense cryptographically
or library wise).

> => you'd like to be in? (:-)

"There is no conspiracy."

On the first read it looked like MD5 was already magicly deprecated, where
the draft will just initiate just that once it will be approved ;-)

Best regards,
   Peter

---

From: Francis Dupont <[email-masked]>
Date: Tue, 10 Jun 2008 17:24:35 +0200

=> it was (according to Olafur). So I've to improve the wording.

   This would introduce a hard cut-over, where with TSIG we have a smooth
   migration from MD5 through SHA1 to SHA-2*.  If MD5 is instantly deprecated
   and replaced by SHA-2, there's no lowest common denominator for two
   implementations.  I must admit, though, I don't know how much operational
   relevance this really has.
   
=> it is an indirect and private usage: indirect because it is only
about how to derive a key, private because both parties must already
trust together. IMHO the best is to minimize choices so SHA-1 should
be avoided.

   
=> I have a nice one.

   There's a difference between deprecating its use and deprecating its
   implementation.  While SHA1 should continue to be implemented, maybe
   the _use_ of SHA-2 could be recommended (if that makes sense
   cryptographically or library wise).

=> this is exactly what I am trying to propose.
   
Thanks