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

Matt Larson <matt@kahlerlarson.org> Thu, 08 February 2018 17:55 UTC

Return-Path: <matt@kahlerlarson.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3311C12D830 for <dnsop@ietfa.amsl.com>; Thu, 8 Feb 2018 09:55:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4ReFHoeIGr1 for <dnsop@ietfa.amsl.com>; Thu, 8 Feb 2018 09:55:12 -0800 (PST)
Received: from smtp117.iad3a.emailsrvr.com (smtp117.iad3a.emailsrvr.com [173.203.187.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 226F612D7E9 for <dnsop@ietf.org>; Thu, 8 Feb 2018 09:55:12 -0800 (PST)
Received: from smtp23.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp23.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 99A802515F; Thu, 8 Feb 2018 12:55:03 -0500 (EST)
X-Auth-ID: matt@kahlerlarson.org
Received: by smtp23.relay.iad3a.emailsrvr.com (Authenticated sender: matt-AT-kahlerlarson.org) with ESMTPSA id 6EA67254E7; Thu, 8 Feb 2018 12:55:03 -0500 (EST)
X-Sender-Id: matt@kahlerlarson.org
Received: from [192.168.1.48] (pool-71-191-205-176.washdc.fios.verizon.net [71.191.205.176]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:465 (trex/5.7.12); Thu, 08 Feb 2018 12:55:03 -0500
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Matt Larson <matt@kahlerlarson.org>
In-Reply-To: <5A7C89B6.2000907@redbarn.org>
Date: Thu, 08 Feb 2018 12:55:02 -0500
X-Mao-Original-Outgoing-Id: 539805302.4811521-067b0c0c0abf0999720262504df78595
Content-Transfer-Encoding: quoted-printable
Message-Id: <C4EABC66-B9EB-427E-8DFD-FBD3B82D8343@kahlerlarson.org>
References: <564E7616-6B47-48E2-B3DC-68A22032F441@icann.org> <20180208.152419.74654265.sthaug@nethelp.no> <A03DAC63-E005-4811-B706-B0284273DE6B@hopcount.ca> <32CB34DD-D682-42D7-B869-5A03057FCCC1@kahlerlarson.org> <5A7C89B6.2000907@redbarn.org>
To: Paul Vixie <paul@redbarn.org>, Joe Abley <jabley@hopcount.ca>, sthaug@nethelp.no, Ed Lewis <edward.lewis@icann.org>, dnsop WG <dnsop@ietf.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jYWLbIB5_zB17Nho169fZBLBgKc>
Subject: Re: [DNSOP] Why new code/old keys? Re: [Ext] Re: sentinel and timing?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Feb 2018 17:55:13 -0000

> On Feb 8, 2018, at 12:32 PM, Paul Vixie <paul@redbarn.org> wrote:
> 
> 
> 
> 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.

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.
> 
> it's doable, but not in the style you suggest, or in a short time.

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