Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 04 Jun 2009 10:43:45 -0400

Please someone take few minutes to say you have read the document,
and your impression of it document !!

I'm extending the LC until June 10'th,
IF we do not have 5 reviews by then the document will be killed!!!!!

         Olafur

At 12:31 20/05/2009, Ólafur Guðmundsson /DNSEXT wrote:
>Reminder
>we still need more reviews.
>
>In particular none of the people that supported adoption has
>submitted one.
>
>         Olafur
>
>Ps: in case you forgot if you supported the document (and agreed to review)
>Roy Arends, Mark Andrews, Olaf Kolkman, Patrik Fältström, Joe Abley,
>Brian Dickson, Edward Lewis, Mike StJohns
>
>At 18:19 08/05/2009, Ólafur Guðmundsson /DNSEXT wrote:
>
>>This note starts a Working Group Last Call for this Standards Track document
>>ending on midnight May 24'th UTZ 2009.
>>
>>URL for the document and its history:
>>http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-tsig-md5-deprecated/
>>
>>This document is on the Standards Track,  The 
>>document updates standards track
>>documents and redefines an IANA registry.
>>
>>Please read the document carefully, and send 
>>your comments to the mailing list.
>>
>>The document process rules in this working group, require that at least
>>5 members of the working to state that they have reviewed the document
>>and there is consensus of support to publish it as a Standards Track RFC.
>>
>>         Olafur (for the chairs)
>>
>>
>>
>>--
>>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/>
>
>
>--
>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/>

--
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: Patrik Fältström <[email-masked]>
Date: Thu, 4 Jun 2009 17:26:24 +0200

I have read the document, and I support it.

    Patrik

On 4 jun 2009, at 16.43, Olafur Gudmundsson wrote:

>>> This document is on the Standards Track,  The document updates  
>>> standards track
>>> Please read the document carefully, and send your comments to the  
>>> mailing list.
>>>

---

From: Shane Kerr <[email-masked]>
Date: Thu, 04 Jun 2009 17:57:24 +0200

Me too.

--
Shane

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Jun 2009 09:03:03 -0700

I have read this document and I do *not* support its adoption. There is no security justification for deprecating the use of HMAC-MD5 in any case, and I do not believe there is security justification for deprecating the use of MD5 between trusted peers (as is the case in TKEY).

Deprecating things that still work fine adds complexity to the protocol, particularly given that the protocol already has options for parties who don't want to use HMAC-MD5 and MD5. If, in the future, there is some actual security justification for the deprecation, we can take this up then.

Note that I'm not one of the five people who volunteered to be reviewers; I have no idea how my active non-support affects the calculation.

--Paul Hoffman, Director
--VPN Consortium

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 4 Jun 2009 18:10:56 +0200

> IF we do not have 5 reviews by then the document will be killed!!!!!

Thanks for the poke.

I support the document. And all the comments below are to be taken in  
the light that if you ask for close review you will get somebody who  
will try to say something that indicates they actually read the  
document :-).

----

In the introduction:

The secret key transaction authentication for DNS

I would start with:

The protocol described in "The Secret Key Transaction Authentication  
for DNS (TSIG)"[RFC2845]  was defined with

-----
Also in the introduction
Context:
security came to be considered lower than expected
Question:
Is there a stable and recognized reference for that claim?

----

Section 2 last sentence

OLD
(i.e., algorithms at a "not Mandatory" requirement level)
NEW
(i.e., requirements that are not at a "Mandatory" requirement level)
ALTERNATIVE
(i.e., requirements that are  at a "Optional" requirement level)

Reason:
"not Mandatory" is not a requirement level that is used in the  
paragraph.

-----

IANA considerations

s!located at http://.*/tsig-algorithm-names!!

Reason:
I don't think it is common to refer to an IANA registry through its  
URL, its name should be unique. Probably wise to check with the RFC  
Editor on what is common.

----

Section 5.

If there is a stable and recognized reference about the claim for SHA1  
that might be useful

----

--Olaf

---

From: Andras Salamon <[email-masked]>
Date: Thu, 4 Jun 2009 17:24:05 +0100

> IF we do not have 5 reviews by then the document will be killed!!!!!

I support advancing draft-ietf-dnsext-tsig-md5-deprecated-03.

-- Andras Salamon                   [email-masked]

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 4 Jun 2009 18:22:49 +0200

On 4 jun 2009, at 18:03, Paul Hoffman wrote:

> I have read this document and I do *not* support its adoption. There  
> is no security justification for deprecating the use of HMAC-MD5 in  
> any case, and I do not believe there is security justification for  
> deprecating the use of MD5 between trusted peers (as is the case in  
> TKEY).
>
> Deprecating things that still work fine adds complexity to the  
> protocol, particularly given that the protocol already has options  
> for parties who don't want to use HMAC-MD5 and MD5. If, in the  
> future, there is some actual security justification for the  
> deprecation, we can take this up then.

Your review crossed mine.

In my review I asked for references because I thought those were  
readily available and I therefore considered my remark an editorial nit.

 From what you just mailed I have the impression that the issue is not  
merely editorial. Would you be willing to lecture me on the difference  
security properties of the different sorts of use? (a reference is  
fine).

For what its worth, if the deprecation of MD5 is needed for TKEY I  
would think that deprecation in (all) other places in a code base  
actually decreases complexity. If SHA256 is mandatory for TKEY and MD5  
is deprecated than it may be that I still have to link MD5 code  
because TSIG needs it; it would be easier to get rid of MD5  
altogether. So from that perspective I would still be supporting the  
document.

--Olaf

---

From: [email-masked]
Date: Thu, 4 Jun 2009 16:24:17 +0000

> IF we do not have 5 reviews by then the document will be killed!!!!!

	read the doc. does what we want it to... move it on.

--bill

---

From: Shane Kerr <[email-masked]>
Date: Thu, 04 Jun 2009 18:28:33 +0200

Paul,

> I have read this document and I do *not* support its adoption. There is no security justification for deprecating the use of HMAC-MD5 in any case, and I do not believe there is security justificati…

The document changes the mandatory support for MD5 to optional. Peers
can continue to use it as long as they want, if they have software that
supports it.

Having fewer mandatory algorithms should make implementations simpler,
not more complex, at least in this case where it is between co-operating
peers.

--
Shane

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Jun 2009 09:56:05 -0700

At 6:22 PM +0200 6/4/09, Olaf Kolkman wrote:
>In my review I asked for references because I thought those were readily available and I therefore considered my remark an editorial nit.

For a protocol assumption like this, that is a reasonable assumption. I believe it is, in this case, misguided.

>From what you just mailed I have the impression that the issue is not merely editorial. Would you be willing to lecture me on the difference security properties of the different sorts of use? (a reference is fine).

The security properties of HMAC-MD5 are described fairly well in <http://eprint.iacr.org/2006/043> and the earlier paper that it cites. I know of no more recent work that contradicts this paper.

The security properties of MD5 in TSIG are, I believe, reliant on the preimage strength of MD5. To date, there has been no indication of any reduction in the preimage strength of MD5. Even if there is such indication, it would have to be a significant reduction (from 128 bits to, say, 96 bits) before there should be any concern about its use in the DNS.

>For what its worth, if the deprecation of MD5 is needed for TKEY I would think that deprecation in (all) other places in a code base actually decreases complexity.

If such deprecation was needed, it would decrease code complexity, but it would greatly increase operational complexity because every system would need to have a policy about when to accept MD5 from an otherwise-trusted peer. Given that many peers are still using MD5, making such decisions usually becomes an ill-informed and possibly random choice. (I guess this is more an argument for the DNSOP WG, but I would hope people here would have some mercy on folks who actually deploy our specs.)

>If SHA256 is mandatory for TKEY and MD5 is deprecated than it may be that I still have to link MD5 code because TSIG needs it; it would be easier to get rid of MD5 altogether. So from that perspective I would still be supporting the document.

If we could make current conformant systems all change at once (flag day, cough cough), that would be fine.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Jun 2009 10:01:38 -0700

At 6:28 PM +0200 6/4/09, Shane Kerr wrote:
>The document changes the mandatory support for MD5 to optional.

...and also to SHOULD NOT:

      The use of MD5 and HMAC-MD5 is NOT RECOMMENDED.

>Peers

For an optional algorithm to work, both sides must be able to process it. This document is recommending that implementations should not use it, so it is likely that some implementations will drop it.

>not more complex, at least in this case where it is between co-operating

Fully agree, but only at the starting point. Downgrading a mandatory algorithm to "SHOULD NOT" causes greater complexity for the people who have to set the security policy for their organizations. Downgrading therefore should only be done when necessary, and it is not necessary here.

--Paul Hoffman, Director
--VPN Consortium

---

From: Scott Rose <[email-masked]>
Date: Thu, 04 Jun 2009 14:45:09 -0400

I have read the document and support it.

(Sent this before, but not sure if it was counted).

Scott

>>> and there is consensus of support to publish it as a Standards Track RFC.

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

---

From: Mark Andrews <[email-masked]>
Date: Fri, 05 Jun 2009 10:36:44 +1000

In message <[email-masked]>, Olafur Gudmundsson wri
> IF we do not have 5 reviews by then the document will be killed!!!!!

	I'm happy with most of it.  I've yet to test if a MD5 TKEY
	client can interoperate with a SHA256 TKEY server and the
	reverse.
 
> At 12:31 20/05/2009, =D3lafur Gu=F0mundsson /DNSEXT wrote:
> >Reminder
> >Roy Arends, Mark Andrews, Olaf Kolkman, Patrik F=E4ltstr=F6m, Joe Abley,
> >At 18:19 08/05/2009, =D3lafur Gu=F0mundsson /DNSEXT wrote:
> >
> >>This note starts a Working Group Last Call for this Standards Track=
>  document
> >>This document is on the Standards Track,  The=20
> >>Please read the document carefully, and send=20
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Federico Lucifredi <[email-masked]>
Date: Thu, 04 Jun 2009 22:37:13 -0400

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

The document looks good overall, and I support it to go forward in the
adoption process.

The only relevant bit that stands out is the absence of "why" from the
doc. It may have some political reason, but it simply is bad practice in
my view. Point 1 states:

"   When the MD5 [RFC1321] security came to be considered lower than
   expected, [RFC4635] standardized new TSIG algorithms based on SHA
   [RFC3174][RFC3874][RFC4634] digests.

   But [RFC4635] did not deprecate the HMAC-MD5 algorithm."

So, there is implicitly a reason to now go back and degrade MD5's status
to optional. I know the papers, you know the papers. Something should be
said here to explain why we are doing this -- or, if there is no reason,
 we should not be doing it.

Just so that it is clear, I _do_ support the change. I think we should
explain why, however, with something along the thought line of "as
research is progressively weakening MD5's cryptographic strength, it is
now time to allocate mandatory status to algorithms not as of yet so
compromised".

I do not like (6), which goes in the opposite direction. We are doing
this because we believe there is a reason to, are we? :

"6. Security Considerations

   This document does not assume anything about the cryptographic
   security of different hash algorithms.  Its purpose is a better
   availability of some security mechanisms in a predictable time frame."

The second statement is good, the first not so much. Again, we are
trying to allocate mandatory status to algorithms that are not as far
down the process of being compromised... there may be  nicer way to put
it, but someone reading the doc should be able to understand why this is
done without outside knowledge of MD5's progressive weakening.

 This is my only correction, but I feel pretty strongly that the doc
should explain /why/ it is doing /what/ it is doing.

 Best -F

-- 
_________________________________________
-- "'Problem' is a bleak word for challenge" - Richard Fish
(Federico L. Lucifredi) - [email-masked] - GnuPG 0x4A73884C

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 5 Jun 2009 08:07:30 -0700

> we should not be doing it.

Exactly. So, if you "know the papers", please point out in any paper why it is justified that we deprecate MD5 in the uses covered in this draft. I can find none, but I might be missing something.

>now time to allocate mandatory status to algorithms not as of yet so

To the best of my knowledge, there is no research weakening MD5's cryptographic strength in preimage attack. Again, I'm happy if you can point out research that I have missed, or show how the now-obvious weakening of MD5's collision resistance affects the use of HMAC-MD5 or MD5 used between trusted parties in TSIG.

>I do not like (6), which goes in the opposite direction.

At least it is honest.

>We are doing
>this because we believe there is a reason to, are we?

So far, no.

>:

Do you feel that way even if the answer is "there is no cryptographic indication that we should be doing this, but people are afraid of the name 'MD5' so we are deprecating it for that reason"?

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Vixie <[email-masked]>
Date: Fri, 05 Jun 2009 16:52:01 +0000

> From: Shane Kerr <[email-masked]>
> Date: Thu, 04 Jun 2009 18:28:33 +0200
> 
> The document changes the mandatory support for MD5 to optional. Peers can
> continue to use it as long as they want, if they have software that
> supports it.

so it's not being deprecated, and the name of the draft is wrong, and the
title of the draft is wrong?  i'd like the word "deprecated" stripped from
the text in that case.  if we're just relaxing the "mandatoriness" then we
ought to say that, to avoid confusing operators and future implementors.

i would be in support of this draft with that clarification.

---

From: Francis Dupont <[email-masked]>
Date: Sat, 06 Jun 2009 17:06:07 +0200

In your previous mail you wrote:

   Also in the introduction
   Context:
   
=> it is the RFC4635 itself but if you'd like a stable and
recognized reference about HMAC-MD5 itself there is none.

=> again there is no claim about HMAC-SHA1 but annoncements about
both weaknesses in SHA-1 (you can get a lot in crypto conferences,
BTW if a significant progress is done the situation could become
not so funny :-) and which is more related to the document about
some usages (which don't include HMAC) of SHA-1 in
http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html
 If you prefer RFCs or I-Ds draft-ietf-dnsext-dnssec-rsasha256-14.txt
or RFC 4509 should be fine and are in the domain...

Thanks

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Sun, 07 Jun 2009 10:41:23 +0200

=> the reason is in (5) and BTW is not a security reason...

---

From: Francis Dupont <[email-masked]>
Date: Sun, 07 Jun 2009 11:10:59 +0200

=> I agree the term deprecate is a bit too strong... but obsolete
is not really better, what do you propose?

Thanks

PS: the two remaining issues are the wording for HMAC-MD5 use (I suggest
to go to lower cases) and the interoperability of TKEY.

---

From: Joe Abley <[email-masked]>
Date: Sun, 7 Jun 2009 11:05:34 -0400

> is not really better, what do you propose?

"no longer recommended"?

Joe

---

From: Paul Vixie <[email-masked]>
Date: Sun, 07 Jun 2009 17:59:04 +0000

> From: Francis Dupont <[email-masked]>
> Date: Sun, 07 Jun 2009 11:10:59 +0200
>    

something like "relax".

---

From: Paul Vixie <[email-masked]>
Date: Sun, 07 Jun 2009 18:00:59 +0000

> From: Joe Abley <[email-masked]>
> Date: Sun, 7 Jun 2009 11:05:34 -0400
> 

that's too strong.

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 7 Jun 2009 14:50:27 -0400

"No longer mandatory"?
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Sun, 07 Jun 2009 18:59:28 +0000

> "No longer mandatory"?

right strength, wrong timeliness.  we need a timeless phrase.

---

From: Joe Abley <[email-masked]>
Date: Sun, 7 Jun 2009 15:00:42 -0400

> right strength, wrong timeliness.  we need a timeless phrase.

"not mandatory"? :-)

Joe

---

From: Paul Vixie <[email-masked]>
Date: Sun, 07 Jun 2009 19:18:30 +0000

> "not mandatory"? :-)

"is henceforth not required"

---

From: Joe Abley <[email-masked]>
Date: Sun, 7 Jun 2009 15:25:50 -0400

> "is henceforth not required"

Since it's Sunday, I'll enlarge this thread by one more message and  
observe that "is henceforth not required" seems directly equivalent to  
"is no longer mandatory" in meaning, strength and timelessness, to me.

Given a choice between the two the latter seems kinder to non-native  
speakers since it avoids the use of the archaic word "henceforth".

We could simplify further and re-cast in a positive sense as "is  
optional".

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 7 Jun 2009 13:52:17 -0700

>is not really better, what do you propose?

As I said earlier, I propose that we do not move this document forward because it is unneeded and will lead to lack of interop for no good reason.

--Paul Hoffman, Director
--VPN Consortium

---

From: Federico Lucifredi <[email-masked]>
Date: Sun, 07 Jun 2009 01:14:23 -0400

> At 10:37 PM -0400 6/4/09, Federico Lucifredi wrote:

[...]

> Exactly. So, if you "know the papers", please point out in any paper why it is justified that we deprecate MD5 in the uses covered in this draft. I can find none, but I might be missing something.

I looked around as well, and from what I can understand the algorithm is
quite crippled in terms of collisions (even more than I recalled), but
it seems that I cannot dig up a weakness impacting Keyed Hash applications.

It may be still good to obsolete SHA-1 and MD5, but, I would still like
to be able to list an objective reason rather than an unmentioned
general feeling of uneasiness with research in an apparently somewhat
unrelated weakness.

> To the best of my knowledge, there is no research weakening MD5's cryptographic strength in preimage attack. Again, I'm happy if you can point out research that I have missed, or show how the now-o…

I can't find any.

>> this because we believe there is a reason to, are we?

Definitely looks that way.

 Best -F

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Sun, 07 Jun 2009 15:52:07 -0700

Paul and all,

  Reluctantly I agree with Paul on this issue.

> As I said earlier, I propose that we do not move this document forward because it is unneeded and will lead to lack of interop for no good reason.

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: Federico Lucifredi <[email-masked]>
Date: Sun, 07 Jun 2009 21:37:27 -0400

Understood. The other mail forwarded to the thread makes the operational
rationale clear.

Perhaps a pointer in the Abstract, or in section (5) that the primary
reason is operational would help clarify first-time reading. It looks
like the initial assumption that there is some security problem is quite
common.

 Best-F

-- 
_________________________________________
-- "'Problem' is a bleak word for challenge" - Richard Fish
(Federico L. Lucifredi) - [email-masked] - GnuPG 0x4A73884C

---

From: Federico Lucifredi <[email-masked]>
Date: Sun, 07 Jun 2009 21:25:51 -0400

Best-F

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 08 Jun 2009 09:49:58 -0400

At 16:52 07/06/2009, Paul Hoffman wrote:
>As I said earlier, I propose that we do not move this document 
>forward because it is unneeded and will lead to lack of interop for 
>no good reason.

Paul,
The reason we are putting this document forward is because it takes more
than a decade to flush in/out new algorithms.
Thus the horizon we need to look at is 2020 not 2010.
Will anyone guarantee that the use of HMAC/MD5 will not be broken by
2020?

As for interoperabilty we have alternatives, we are promoting the
alternatives by changing the requirement level. Unlike DNSSEC DNSKEY
algorithms, TSIG is either between "consenting adults" or has a
handshake (TKEY) thus a algorithm negotiation can take place.

                 Olafur

---

From: [email-masked]
Date: Mon, 8 Jun 2009 14:02:30 +0000

> Will anyone guarantee that the use of HMAC/MD5 will not be broken by

	are you a betting man?  I'm sure I can get someone to take that
	bet.

--bill

---

From: Federico Lucifredi <[email-masked]>
Date: Mon, 08 Jun 2009 12:09:11 -0400

>From one side, breaking a Keyed Hash is harder than finding collisions,
so that may be a more open statement than it sounds.

On the other side, betting on a crypto algorithm to remain inviolate for
a full solar cycle may be rather gutsy. The reality is that we cannot
guarantee any cryptographic algorithm will remain inviolate, much less
for an "endecade".

So, I remain satisfied with the operational assertion - provided it is
made clearer to readers, as many come in assuming some of MD5's
vulnerabilities got it demoted, not its phaseout from libraries (which,
of course, indirectly comes from its vulnerabilities, but not one
affecting HMAC).

Otherwise, it may easily look to a reader as if the IETF is practicing
"security through obscurity" here: we understand MD5 more, and even tho
keyed hashing is not broken, we understand SHA-256 less, so we feel more
comfy with it.  Not a label I wish to attach :)

 Best -F

---

From: Paul Vixie <[email-masked]>
Date: Mon, 08 Jun 2009 16:57:23 +0000

> Date: Mon, 08 Jun 2009 09:49:58 -0400
> From: Olafur Gudmundsson <[email-masked]>
> 
> Paul,
> 
> than a decade to flush in/out new algorithms.  Thus the horizon we need
> to look at is 2020 not 2010.  Will anyone guarantee that the use of
> HMAC/MD5 will not be broken by 2020?

i don't think there's anyone around who will guarantee the use of any crypto
in that time frame.  (we're going to have quantum computers at some point.)

until there is a known reason to "deprecate" all we can legitly do is "relax".

> algorithms, TSIG is either between "consenting adults" or has a handshake
> (TKEY) thus a algorithm negotiation can take place.

i'm fine with promoting the alternatives.  but not with deprecating something
that is not broken.  let's just relax the requirement for HMAC-MD5 so that
operators, and future implementors, have the guideance they need.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 8 Jun 2009 11:24:59 -0700

>than a decade to flush in/out new algorithms.

I do not see the word "flush" in the current document. We are currently discussing what the document is trying to say, and you are the first to propose that.

>Thus the horizon we need to look at is 2020 not 2010.

Fully disagree. We need to look at the horizon of "when are vulnerabilites that affect the protocol seen".

>Will anyone guarantee that the use of HMAC/MD5 will not be broken by

That's an interesting question. Given the current crypto literature, if HMAC-MD5 is broken in 2020, so will HMAC-SHA1 and HMAC-SHA256. I doubt that you are suggesting that we expand the current document to remove all HMACs from use in the DNS.

>handshake (TKEY) thus a algorithm negotiation can take place.

Exactly right. So, there is no use to deprecating the algorithms until there is a known problem. At that time, all pairs of DNS folks can decide whether or not they still want to use MD5 or HMAC-MD5. We should probably change the protocol requirements at that time.

--Paul Hoffman, Director
--VPN Consortium