rndc valid key typesSo, I've spent some time looking at the man pages and googling without any definitive answer.
I'm generating some new rndc keys for my bind9 config. (9.11.3 in this particular case, if it matters.)
rndc-confgen has quite a number of options for the key-type - but I'm not sure what BIND9 will handle for RNDC.
I've seen reports that only HMAC-MD5 is the only valid key type.
Just before posting this, I checked the RNDC man page and found this:
[At least I saved myself some public embarrassment! :) ]
rndc communicates with the name server over a TCP connection, sending commands authenticated with digital signatures. In the current versions of rndc and named, the only supported authentication algorithms are HMAC-MD5 (for compatibility), HMAC-SHA1, HMAC-SHA224, HMAC-SHA256 (default), HMAC-SHA384 and HMAC-SHA512. They use a shared secret on each end of the connection. This provides TSIG-style authentication for the command request and the name server's response. All commands sent over the channel must be signed by a key_id known to the server.
Still, the root cause for my query....
Is there any (security) reason/implications to use something "better" than MD5?
I'd lean toward something like HMAC-SHA256/384/512.
Perhaps there's a discussion somewhere I haven't found - and I'd be glad to be pointed to that, instead of taking someone's time re-typing a bunch of details. But I can't seem to find anything.
I assume it might be easier to forge an update for rndc with an MD5 key, right?
Is there any reason not to select the strongest - HMAC-SHA512?
Just wanting to be sure I understand the implications of any particular choice.
On Tue, Jul 07, 2020 at 04:32:37PM -0700, Gregory Sloop wrote:
> I've seen reports that only HMAC-MD5 is the only valid key type.
That was the case at one time, but hasn't been for years.
> Is there any (security) reason/implications to use something "better"
> than MD5?
MD5 is broken (as is SHA1). In this specific context, a forged rndc message
is probably impracticable on any reasonable time scale, and I wouldn't fear
for security if I were using them. *But*, they're broken, and crypto
people don't like keeping broken things around, so I wouldn't count on them
being supported forever. We've already removed MD5 support in the context
of DNSSEC keys; TSIG could come next.
So, if you want to generate a key and not have to worry about generating
another one in a year or two, I would advise against MD5 or SHA1.
> Is there any reason not to select the strongest - HMAC-SHA512?
No, go ahead. I tend to use sha256, just because it's the default