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

From: Andrew Sullivan <[email-masked]>
Date: Mon, 26 May 2008 16:21:56 -0400

Dear colleagues,

This message starts a seven-day request to the Working Group asking
whether we want to adopt draft-dupont-dnsext-tsig-md5-deprecated as a
working group item.

You can find the text of the draft at
<http://tools.ietf.org/id/draft-dupont-dnsext-tsig-md5-deprecated-00.txt>.  

Please respond to the call by 21:00 UTC on 2008-06-02 if you wish that
the draft be adopted, or if you wish that it not be adopted.  Please
state your reasons, especially if you are in opposition.

We note that there was already one comment in support of adopting it,
at
<http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00687.html>.
We'll consider that an expression of support for the purposes of
deciding.

Best regards,
Olafur & Andrew

-- 
Andrew Sullivan
[email-masked]
+1 503 667 4564 x104
http://www.commandprompt.com/

--
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: "Roy Arends" <[email-masked]>
Date: Mon, 26 May 2008 22:59:06 +0200

Andrew Sullivan wrote on 05/26/2008 10:21:56 PM:

> <http://tools.ietf.org/id/draft-dupont-dnsext-tsig-md5-deprecated-00.txt
>. 
> 
> <http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00687.html
>.

I support the adoption of draft-dupont-dnsext-tsig-md5-deprecated.

Roy Arends
Nominet UK

---

From: Mark Andrews <[email-masked]>
Date: Tue, 27 May 2008 10:18:21 +1000

I support the adoption of draft-dupont-dnsext-tsig-md5-deprecated.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Olaf Kolkman <[email-masked]>
Date: Tue, 27 May 2008 08:20:16 +0200

> whether we want to adopt draft-dupont-dnsext-tsig-md5-deprecated as a

support

--Olaf

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 27 May 2008 08:56:17 +0200

> state your reasons, especially if you are in opposition.

I support this.

    Patrik

---

From: Joe Abley <[email-masked]>
Date: Tue, 27 May 2008 14:28:14 +0000

> whether we want to adopt draft-dupont-dnsext-tsig-md5-deprecated as a

I have read this document, and support its adoption by the working  
group.

Joe

---

From: Brian Dickson <[email-masked]>
Date: Wed, 28 May 2008 23:55:38 -0400

> whether we want to adopt draft-dupont-dnsext-tsig-md5-deprecated as a

I have read this document, and support its adoption by the working group.

Brian

---

From: Edward Lewis <[email-masked]>
Date: Thu, 29 May 2008 11:44:24 -0400

><http://tools.ietf.org/id/draft-dupont-dnsext-tsig-md5-deprecated-00.txt>.

Sure, adopt it.

I have a request (for the editor) - can the security considerations 
reference material with greater detail on why MD5 is a bad idea?  No 
need to write more there, just some references to material that goes 
into the crypto-gunk reasons.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.

---

From: Peter Koch <[email-masked]>
Date: Thu, 29 May 2008 21:08:20 +0200

> state your reasons, especially if you are in opposition.

favoring adoption does not necessarily mean agreeing with the draft, so
here's my "yes" vote.  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

>                       Deprecated HMAC MD5 in TSIG

Deprecation of HMAC MD5 in the DNS TSIG and TKEY Resource Records

>    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?

> 2.  IANA Considerations

Move this to the end.

>    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 ;-)

> 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?

>    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.

> 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

>    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.
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?

> 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.

>    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.
>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.  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?

> 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? :-)

> 7.  References
> 
> 7.1.  Normative References

see above for SHA-256.

-Peter

---

From: Michael StJohns <[email-masked]>
Date: Thu, 29 May 2008 15:53:20 -0400

Support adoption and suggest immediate referral to WG last call for publication as an RFC.