Subject: [saag] Use of TSIG

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 3 Jan 2018 16:07:51 -0500

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.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 3 Jan 2018 16:17:23 -0500

Hi,

> I decided to configure using only sources that I find on the Web that are

I don't understand this plan.  You're saying that you have forsaken
the manual for your software in favour of random things you find on
the Internet?  I mean, whatever floats your boat, but I often find
that a comprehensive manual for my software contains better
information than things I learned in the virtual schoolyard.

> Some of the best
> is n how to generate TSIG keys.

In that manual you forsook, you might have discovered the command
tsig-keygen.

> rather than helps. And I hadn't spotted the reference to 'DNSSEC' until I

For reasons I don't fully understand, TSIG and the DNS Security
Extensions are occasionally treated together somehow as "DNSSEC".
They have little to do with one another.  TSIG is a shared secret
approach.

> this'. Whether ICANN/IETF/OTA is best for this, I don't know but it needs

It seems to me that the bind-users list is what you're after.  This
isn't a DNS protocol problem, it's an implementation issue, since
every implementation does it differently.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 Jan 2018 16:28:43 -0500

> On Jan 3, 2018, at 4:07 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> 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.

PK is not actually more secure when the verifier and relying party are compute
resources operated by the same entity.  Indeed symmetric crypto does not suffer
from the potential failure of current PK algorithms if/when scalable quantum
computers show up.

That said, a PK alternative to TSIG is available:

  https://tools.ietf.org/html/rfc2931

You are of course right that there's lots of bad advice on the Internet, and
that giving too much rope to users is liable to reduce security when they make
poor choices (and don't know the difference).

This means that administration tools should make it easy to choose sensible
settings, and (more) difficult to choose "exotic" settings.  When tools are
completely neutral on parameter choices, the resulting diversity is generally
counter-productive.  See for example:

   https://lists.dns-oarc.net/pipermail/dns-operations/2017-December/017125.html
 
-- 
	Viktor.

---

From: Tim Hollebeek <[email-masked]>
Date: Wed, 3 Jan 2018 21:39:19 +0000

>    https://lists.dns-oarc.net/pipermail/dns-operations/2017-

Unfortunately, of course, the proper sensible settings change with time.
I'm all for sane defaults, but it doesn't fix the problem of a server that
was
configured 20+ years ago with sensible settings.

It really would be nice if I could set my security to MEDIUM and my device
could reconfigure itself appropriately over time as things change.

Heck, it'd be nice if it could alert me that my recommended settings are no
longer recommended.  I do think there's lots of room for better software
in this area, especially for long lived servers and devices ...

-Tim

---

From: Adam Montville <[email-masked]>
Date: Wed, 03 Jan 2018 21:42:38 +0000

There are venues that exist to define secure configurations for
technologies, including implementation-specific DNS services.
https://www.cisecurity.org/benchmark/bind/

Kind regards,

Adam

On Wed, Jan 3, 2018 at 3:39 PM Tim Hollebeek <[email-masked]>
wrote:

> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 Jan 2018 16:51:00 -0500

> On Jan 3, 2018, at 4:39 PM, Tim Hollebeek <[email-masked]> wrote:
> 
> was configured 20+ years ago with sensible settings.

Yes, that's difficult, but not a reason to give up.

> could reconfigure itself appropriately over time as things change.

Postfix TLS cipher selection does essentially this.  The interface for
the general user is:

	smtp_tls_ciphers = medium
	smtpd_tls_ciphers = medim

however, an advanced interface is available, but users are warned away
from tinkering with it.  This enables future modification of the meaning
of "medium".

	tls_medium_cipherlist = ...

The default value of that setting changes as needed with new releases and
also the underlying OpenSSL library also modifies MEDIUM from time to time
when algorithms lose their shine.

So security is maintained either when users upgrade, or if that's not an
option by following authoritative advice to update the underlying low-level
parameters.

Presenting simple interfaces to most users and warning them away from
getting in over their head by tinkering with parameters they don't
understand is IMHO a fundamental part of delivering usable security.

-- 
	Viktor.

---

From: Evan Hunt <[email-masked]>
Date: Wed, 3 Jan 2018 22:08:28 +0000

> I decided to configure using only sources that I find on the Web that are

I'm not sure why you decided to do that, but I can tell you that what
you're reading is massively out of date.  If you want to generate a TSIG
key, use "tsig-keygen". It uses an appropriate source of randomness and
produces output in a format suitable for use in named.conf.

What was the source of the information you found?

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 3 Jan 2018 17:51:37 -0500

> information than things I learned in the virtual schoolyard.

​I am saying I am following what I believe to be the approach followed by
90% of network admins.​

​My interest is to find out why things are going wrong. Wishing that people
will read manuals is like wishing for a unicorn.​

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 03 Jan 2018 15:11:30 -0800

> will read manuals is like wishing for a unicorn.​

Is there anything any of us can do about what you found? Short of 
someone going and removing links to web pages that have wrong 
information, I don't see how we can make the situation better.

--Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 Jan 2018 18:19:57 -0500

> On Jan 3, 2018, at 6:11 PM, Paul Hoffman <[email-masked]> wrote:
> 
> Is there anything any of us can do about what you found? Short of someone
> going and removing links to web pages that have wrong information, I don't
> see how we can make the situation better.

Yes.  Software should offer an overlay of simplified (mostly idiot-proof)
interfaces that will be obviously the right ones to use for most users, and
advanced interfaces for unanticipated mitigations for future issues should
not also be the routine day to day configuration interfaces.

That's my favourite mitigation, there are of course others.
 
-- 
	Viktor.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 3 Jan 2018 23:22:41 +0000

On 03/01/18 23:11, Paul Hoffman wrote:
> 
> Is there anything any of us can do about what you found?

Yeah, not much really.

We could include more appendices in RFCs that show how to
get started with some widely used implementation, e.g. for
crypto things I like RFCs that show how to get started and
generate/check test vectors using the openssl command line.

Other than that it comes down to the person reading the
RFC/manual/stackexchange/blog to know what's crap and what
isn't. Educating the general system user/admin about that
seems beyond the IETF's remit to me too.

S

-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 03 Jan 2018 19:09:32 -0500

> seems beyond the IETF's remit to me too.

As long as the IETF keeps user interface and user experience (even of
system administrators) outside of its scope of work, we will continue to
encourage the production of footguns.

I don't particularly want to have lengthy IETF-style discussions about
UI/UX, but our guidance is usually aimed at technical exhaustiveness (if
not exhaustion), and we rarely provide guidance on minimal, simplistic
profiles.

I'm guilty of this too, in IETF contexts.  :( For example, In
retrospect, i think our DPRIVE authentication profiles draft should not
have outlined quite so many options.

i think we would do well to encourage the writing of knowledgable,
highly-opinionated informational drafts that set forth narrow "best
practices" for software implementers.

When i compare the user (administrator) experience with wireguard [0]
against the user (administrator) experience of any of the range of IPSec
implementations i've worked with [1], it's night and day.  It's not
surprising to me that the design-by-committee and
curse-of-the-deployed-base that produced today's IPSec doesn't have the
same clarity of vision and ease of use as Donenfeld's singleminded
focus.  But it's pretty depressing to me that even skilled implementors
can't pull together a "default install" setup that Just Works based on
IETF standards.

I understand that we nerds love power and flexibility and expansive
toolkits, but if we want our tools to have a positive impact on people,
we need to spend a lot more time thinking about the shortest path to
installation, and make sure our implementations optimize for it.

        --dkg

[0] https://wireguard.com/
[1] https://strongswan.org/
    https://libreswan.org/
    http://www.kame.net/
    http://www.unix-ag.uni-kl.de/~massar/vpnc/
    etc…

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 3 Jan 2018 19:26:26 -0500

​In addition to the points DKG makes, a requirement to describe how to
configure a system properly entails a requirement for such a configuration
to 1) exist and 2) be capable of being described clearly. I am pretty sure
the Kaminsky bug would have been recognized much earlier if the design of
glue records wasn't so bjorked in the first place.

The mindset of the typical engineer is 'make it work'. That is not at all
the same as the security engineering mindset of 'make it safe'.

I agree that getting people to listen is a problem. But there are two
groups corporations are generally forced to listen to: their insurers and
politicians.

---

From: Randy Bush <[email-masked]>
Date: Thu, 04 Jan 2018 15:46:51 +0900

the prudent operator/sysadmin does not swollow without analysis data
from the net of a thousand lies.