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

[Matt Larson <[e-mail]>]

> On Feb 8, 2018, at 9:43 AM, Joe Abley <[e-mail]> wrote:
> 
> 
> 
>> On 8 Feb 2018, at 09:24, [e-mail] wrote:
>> 
>>> 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.
>> 
>> Speaking only for myself - I have done many BIND upgrades without config
>> file changes (and I basically expect this to work).
> 
> 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.

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