Subject: [DNSOP] Why new code/old keys? Re: [Ext] Re: sentinel and timing?

From: Edward Lewis <[email-masked]>
Date: Thu, 8 Feb 2018 14:18:55 +0000

On 2/8/18, 01:02, "DNSOP on behalf of Paul Wouters" wrote:
    
>We have a giant hole in our understanding of why there are update nameservers running the latest software with the older keys.

If just to spread rumors, I heard the following as early as November, 2016.  One of the issues is that operators update code without updating configuration files.  I.e., a BIND upgraded today might be using a configuration file from the pre-managed-key days.

I am not saying this theory has been put to the test, but it is compelling.  This hypothesis is in the ICANN deck on the KSK rollover used throughout 2017 (until the postponement).

---

From: [email-masked]
Date: Thu, 08 Feb 2018 15:24:19 +0100 (CET)

> If just to spread rumors, I heard the following as early as November, 2016.  One of the issues is that operators update code without updating configuration files.  I.e., a BIND upgraded today might…

Speaking only for myself - I have done many BIND upgrades without config
file changes (and I basically expect this to work).

Steinar Haug, AS2116

---

From: Ray Bellis <[email-masked]>
Date: Thu, 8 Feb 2018 14:43:14 +0000

On 08/02/2018 14:18, Edward Lewis wrote:

> I am not saying this theory has been put to the test, but it is
> compelling.  This hypothesis is in the ICANN deck on the KSK rollover
> used throughout 2017 (until the postponement).

Another hypothesis is configurations where the directory in which BIND
is looking for its files is not writable, preventing saving of the
updated keys.

Some O/S vendors do ship their BIND packages configured this way by
default :(

Ray

---

From: Joe Abley <[email-masked]>
Date: Thu, 8 Feb 2018 09:43:15 -0500

> On 8 Feb 2018, at 09:24, [email-masked] wrote:
> 

The problem is that until the first KSK rollover,

  best current practice for configuring DNSSEC validation in 2008 (without RFC5011)

and

  best current practice for configuring DNSSEC validation in 2018 (with RFC5011)

are functionally identical; there's no failure evident from using trusted-keys vs. managed-keys in your configuration, and BIND9's fastidious backwards compatibility means that old configurations continue to work even if "best current practice" with respect to the facilities implemented in BIND9 have changed.

Joe

---

From: Matt Larson <[email-masked]>
Date: Thu, 8 Feb 2018 10:24:36 -0500

> On Feb 8, 2018, at 9:43 AM, Joe Abley <[email-masked]> wrote:
> 
> 
> 

I would love to see BIND's trusted-keys syntax deprecated. Not the ability to configure a trust anchor statically, mind you, just the syntax. Changing the syntax and refusing to start with trusted-key in the configuration file would force those who are dragging old config files behind them unchanged to update.

Maybe something like this:

managed-keys {
 "." initial-key 257 3 8
   "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
    FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
    bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
    X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
    W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
    Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
    QxA+Uk1ihz0=";
 managed no; // Behave as if this were "trusted-keys"
};

(But please let's not bikeshed the syntax of a possible implementation...)

Matt

---

From: Paul Vixie <[email-masked]>
Date: Thu, 08 Feb 2018 09:18:52 -0800

> file changes (and I basically expect this to work).

i apologize, again, for the config file from last-bind8, not working in 
all cases with first-bind9. i don't work at ISC any more, but i think i 
can safely predict that this won't happen again.

-- 
P Vixie

---

From: [email-masked]
Date: Thu, 08 Feb 2018 18:31:03 +0100 (CET)

> can safely predict that this won't happen again.

Well now - BIND8 and BIND9 are rather different. However, I have
upgraded multiple times on BIND9 without any config change - it's
certainly possible I've been spoiled. I *did* get bitten recently
when, on a specific server with no IPv6 connectivity, I had to add

    listen-on-v6    { none; };

to get things running. But that's really my only complaint, and a
rather small one at that!

Steinar Haug, AS2116

---

From: Paul Vixie <[email-masked]>
Date: Thu, 08 Feb 2018 09:32:38 -0800

Matt Larson wrote:
> I would love to see BIND's trusted-keys syntax deprecated. Not the
> ability to configure a trust anchor statically, mind you, just the
> syntax. Changing the syntax and refusing to start with trusted-key in
> the configuration file would force those who are dragging old config
> files behind them unchanged to update.

tough love is hard to give away. BIND9 ships inside a lot of packaged 
Linux systems, and i don't imagine that ISC would ask or that RH would 
agree to (another) deliberate invalidation of a working config file.

the old one can be made to generate syslog warnings. but there would be 
some lengthy crossover period during which both old and new config 
worked, so that eventually, ISC and RH could include a python or perl 
script that would convert old format to new.

it's doable, but not in the style you suggest, or in a short time.

-- 
P Vixie

---

From: Matt Larson <[email-masked]>
Date: Thu, 8 Feb 2018 12:55:02 -0500

> On Feb 8, 2018, at 12:32 PM, Paul Vixie <[email-masked]> wrote:
> 
> 
> 
> Matt Larson wrote:
> tough love is hard to give away. BIND9 ships inside a lot of packaged Linux systems, and i don't imagine that ISC would ask or that RH would agree to (another) deliberate invalidation of a working config file.

Out of curiosity, what other changes have there been that deliberately invalidated a working config?

> the old one can be made to generate syslog warnings. but there would be some lengthy crossover period during which both old and new config worked, so that eventually, ISC and RH could include a python or perl script that would convert old format to new.
> 

I appreciate that line of reasoning when applied to invalidating features that don't have harmful consequences if used. But in the specific case we're talking about, the circumstances matter: I suggest that it's better to have the server refuse to start with a clear syslog message to force someone to adjust a harmful config rather than have the server start but fail to resolve queries by mysteriously returning SERVFAIL to everything.

I realize that because of islands of security, there are keys other than the root KSK configured statically, so my reasoning does apply to every situation. But I'd bet lots of money that the vast majority of trusted-key statements are configuring KSK-2010. Another option, then, would be to allow trusted-keys in the general case but refuse to start if the trusted-key is for the root. Sometimes the root is special. (I see Ed Lewis approaching the mic now...)

At the very least, a "trusted-keys for the root KSK considered harmful" syslog message would be a hopefully easy and non-controversial first step in the right direction.

I understand that this is a big request, but I ask the ISC folks to consider it seriously. 

Matt

---

From: Paul Vixie <[email-masked]>
Date: Thu, 08 Feb 2018 10:06:02 -0800

Matt Larson wrote:
> Out of curiosity, what other changes have there been that
> deliberately invalidated a working config?

the big one was last-bind8 to first-bind9. there were also some minor 
ones over the years like changing the default for allow-query to be 
localnets rather than any. since it hasn't happened in the years i've 
been gone from ISC, i think we can safely assign blame and move on.

> I appreciate that line of reasoning when applied to invalidating
> features that don't have harmful consequences if used. But in the
> specific case we're talking about, the circumstances matter: I
> suggest that it's better to have the server refuse to start with a
> clear syslog message to force someone to adjust a harmful config
> rather than have the server start but fail to resolve queries by
> mysteriously returning SERVFAIL to everything.

there's going to have to be a third way. if that's due to happen, we can 
expect the BIND9 embedders and ISC to work together to patch it in an 
way that disables DNSSEC validation if it recognizes some badness of 
some kind. running off the rails into a ditch won't be allowed to 
happen, for anyone whose BIND9 gets patched regularly. even if this 
means recognizing KSK-2010 specifically, in hard code.

> At the very least, a "trusted-keys for the root KSK considered
> harmful" syslog message would be a hopefully easy and
> non-controversial first step in the right direction.

i think that's entirely reasonable, and based on BIND9's syslogging when 
its hints file is seen to be out of date (doesn't match priming), i 
think there's sufficient precedent. but i do think we ought to be 
realistic as to whether the 99%'ers will ever read their syslog files.

-- 
P Vixie

---

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 8 Feb 2018 23:47:34 +0530

On Thu, Feb 08, 2018 at 10:06:02AM -0800, Paul Vixie wrote:
> i think that's entirely reasonable, and based on BIND9's syslogging when its
> hints file is seen to be out of date (doesn't match priming), i think
> there's sufficient precedent. but i do think we ought to be realistic as to
> whether the 99%'ers will ever read their syslog files.

I would've sworn this was already done. It looks like it was discussed
on ticket #43670 and then the ticket was silently closed. Re-opening.

		Mukund

---

From: Mark Andrews <[email-masked]>
Date: Fri, 9 Feb 2018 09:21:47 +1100

Managed keys presumes the operator is actually using RFC5011 timings
to roll their keys.  There are very few zones that have publicly
said they are using RFC 5011.

Named gets used on private networks.  Those networks can use DNSSEC
they can decide to use trusted-keys rather than RFC 5011.

Mark

> On 9 Feb 2018, at 2:24 am, Matt Larson <[email-masked]> wrote:
> 
>> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]