[dns-operations] Use of TSIG

[Phillip Hallam-Baker]

As folk who are following a certain FB page know, I am configuring a BIND
server direct for the first time in a while and so just for the heck of it,
I decided to configure using only sources that I find on the Web that are
not actual manuals.

This has turned into an audit of the 'advice' out there. Some of the best
is n how to generate TSIG keys. Take this for example:

$echo $(date) | openssl base64

Because 2^20 is a huge key space for any attacker to brute force.

And then there was this gem:

The public key, *kprod.tsigkey.+157+57861.key* contains:

prod.tsigkey. IN KEY 512 3 157 wzs+I/9e6CthD0BT3Uh00w==

While the private key, *Kprod.tsigkey.+157+57861.private*contains:

Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: wzs+I/9e6CthD0BT3Uh00w==
Bits: AAA=

Now that we have generated the DNSSEC keys, we need to put them to use and
incorporate them into our configuration.

This is the sort of explanation where a little bit of knowledge hinders
rather than helps. And I hadn't spotted the reference to 'DNSSEC' until I
cam to cut and paste.


This is really not acceptable. In 2018 we have to set a different standard
for security:

A protocol is not secure unless the typical administrator following the
line of least resistance to do their job is likely to configure it
correctly.

This is essentially the old orange book criteria 'secure by default'.


OK so how do we get from where we are to where we should be?

In the short term we need a set of instructions on how to configure DNS
securely that has had some expert review. And by 'secure' I mean, conforms
to a high level of security best practice not 'we haven't had issues with
this'. Whether ICANN/IETF/OTA is best for this, I don't know but it needs
to come into being.

Another thing we should do is to remove as many prat-falls from the process
as possible. TSIG is an adequate approach to authenticating zone transfers,
it is not an adequate approach to managing authentication secrets. These
should always be public key pairs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20180103/faa62fac/attachment.html>