Remove HMAC-MD5 support from TSIG

[tmthrgd]

The Wikipedia article for TSIG claims that HMAC-MD5 is "still in common usage", but doesn't provide any source for this. If there's no one who desperately needs this, I'd like to remove it entirely.

MD5 is a severely broken algorithm so it would be great to get it out of this library, even removing legacy support.

Considering that the TSIG algorithm is set by the TSIG record and not by the secret key (!! see the JWT token mess), an exploitable weakness in HMAC-MD5 could allow easy forging of TSIG records even on systems that do not otherwise use MD5.

[miekg]

this might need IETF action, but I agree with the sentiment of just removing this.

[tmthrgd]

@miekg It would be good to have it formally deprecated. This is an easy revert at least if people need HMAC-MD5 and can’t easily update.

[apantelopoulosNS1]

Hey @miekg, I am part of the DNS team in NS1 and just saw that the support for hmac-md5 algorithm is removed. Unfortunately, our customers still make heavy use of this algorithm in our systems thus we have to support it. Further, RFC https://tools.ietf.org/html/rfc6151 also states that it is not urgent to stop using HMAC-MD5 (Section 2, Security Considerations).

We have a plan of migrating customers eventually away from hmac-md5, but this will take time. In the meantime, is it possible to re-add support for it in the library since it prohibits us from updating to newer versions?

[tmthrgd]

@apantelopoulosNS1 That is quite unfortunate, ridding this library of ancient algorithms is definitely a goal of mine. I would encourage you to migrate as promptly as you can, because it really isn’t a good algorithm or something that should be kept around anywhere at all.

Just for the record RFC 6151 is now a full decade old, so I wouldn’t rush to it for security advice. I can’t seem to find much recent discussion on how secure HMAC-MD5 is or isn’t though.

I can open a revert PR, but now we have a TsigProvider you could potentially quite trivially implement it yourself by copying the built in HMAC provider code and adding it. Would that satisfy your use case or shall I open a revert PR?

[apantelopoulosNS1]

Hello @tmthrgd, thanks for responding so quickly! We decided to use TsigProvider as you pointed out to implement this functionality, thus there is no need for a revert PR. 👍

[dmavrommatis]

@tmthrgd hey! I have a question regarding the TsigProvider interface. It seems that the provider functions are not exposed and we can't use them?

(original comment/question)
#1254 (comment)

[dmavrommatis]

@tmthrgd I think TsigProvider is not in a state that can be used right now. It's only supported when you are client and there is no use of it in xfr or server.

Also, the TsigProvider does not support using the current secret for the processed packet so when acting as a server you should know all the secrets beforehand which is not always possible.
https://github.com/miekg/dns/blob/master/client.go#L349
co.TsigSecret[t.Hdr.Name] vs just co.TsigProvider

This makes support of MD5 nearly impossible unless we change the whole TsigProvider implementation to also use the t.Hdr.Name which breaks backwards compatibility.

Please tell me if I am wrong with the above mentioned.