Re: [DNSOP] [Ext] DNSSEC Strict Mode

Joe Abley <jabley@hopcount.ca> Thu, 25 February 2021 15:11 UTC

Return-Path: <jabley@hopcount.ca>
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 C66153A1B00 for <dnsop@ietfa.amsl.com>; Thu, 25 Feb 2021 07:11:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 tO5B3EyJZ9HB for <dnsop@ietfa.amsl.com>; Thu, 25 Feb 2021 07:11:14 -0800 (PST)
Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A77D3A1AFE for <dnsop@ietf.org>; Thu, 25 Feb 2021 07:11:14 -0800 (PST)
Received: by mail-qv1-xf2f.google.com with SMTP id p12so2884121qvv.5 for <dnsop@ietf.org>; Thu, 25 Feb 2021 07:11:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=UVgWYwCaNTVoy9TS273+GJOjyvaXlRQ0SlnZmyKGm4E=; b=JhOW6rEUgsWRPKxv4rvyVjDypPxHasZshN0oXHJ4QJBChHWsMXoVRt6Qn81Ywjx6uG jzYJehDGdUMEKfBZ69ec2Q5zjadIZ0ftBK4zi2rpLocRL3DfRrQyXh1olHjB5NqN1NXY GVgHWOsneKFx0pzk57IhSicNYvKtDElYZRhlU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=UVgWYwCaNTVoy9TS273+GJOjyvaXlRQ0SlnZmyKGm4E=; b=O+BXcS7OIQPmbS89S7iXU+FgU1Ej2dhw7JcKTCkHIrYoh59R+XL6p5Wxd39yG6bsS7 eWG5uoPgNftcs01w9DCdlrddWsE9l5YyxqoVfQN7S+UcJXTXNNaI65cArlAETj8W31OG udAPGiSII0IQ3RyJosdWGpA42R1fUqLKn5DBIBSgcmoQ9iGUwKAtMyh9D7gGgwj+9Dxt MNKtqGLG0he6J81+Hl8PObmFFkMjxHkr6OT0HcPZ8oTR+KXaBrPllIwZwvtRgVgAp3Dt T/Yi9gyfRms0jwK1G055EEUtq76XH/daBVC1gExjgN6YpGG3j0LQRhGyXHzC/qHKsvl1 scDg==
X-Gm-Message-State: AOAM532JcKjjOotMJlFxC49s9RWcLiQj9bcCm5dsOzA0VvoF9Q8jLMmE sS8y5/thRN1YsYOCjzVrJuW9Tg==
X-Google-Smtp-Source: ABdhPJxySc2P5XzpeyZYZl98v+5Tb7FZ6pGRa8tRRUdxlNj8Gr2iDg3Gt6kh6k2YbiBIXQMdyfsO7A==
X-Received: by 2002:a0c:8121:: with SMTP id 30mr1732137qvc.27.1614265873487; Thu, 25 Feb 2021 07:11:13 -0800 (PST)
Received: from ?IPv6:2607:f2c0:e784:c7:c4cb:3623:5154:56c4? ([2607:f2c0:e784:c7:c4cb:3623:5154:56c4]) by smtp.gmail.com with ESMTPSA id u13sm3621713qtq.87.2021.02.25.07.11.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Feb 2021 07:11:12 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Joe Abley <jabley@hopcount.ca>
Mime-Version: 1.0 (1.0)
Date: Thu, 25 Feb 2021 10:11:10 -0500
Message-Id: <A84CDA86-FB37-4086-AF05-2E25BCB12766@hopcount.ca>
References: <17704496-1D7E-4891-8ADB-4D6002D070D3@wisser.se>
Cc: Mark Andrews <marka@isc.org>, Ben Schwartz <bemasc@google.com>, Paul Hoffman <paul.hoffman@icann.org>, Samuel Weiler <weiler@watson.org>, dnsop <dnsop@ietf.org>
In-Reply-To: <17704496-1D7E-4891-8ADB-4D6002D070D3@wisser.se>
To: Ulrich Wisser <ulrich=40wisser.se@dmarc.ietf.org>
X-Mailer: iPad Mail (18D52)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/-ScywPhQrxsbvNcIX2n9thfJsxg>
Subject: Re: [DNSOP] [Ext] DNSSEC Strict Mode
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 25 Feb 2021 15:11:16 -0000

Hi Ulrich,

On Feb 25, 2021, at 06:53, Ulrich Wisser <ulrich=40wisser.se@dmarc.ietf.org> wrote:

> But this is a real world problem, one that is holding DNSSEC back.
> If you buy DNS operations the operator will usually tell you what algorithm they use, you have no choice in that.

This feels like one of those areas where more specificity is needed. "DNS operations" is is over-broad; what you mean, I think, is "if you outsource zone-signing". If you sign yourself and distribute your zone to external DNS operators then you can add and drop vendors without worrying about key rollovers, for example.

> Now if your new operator doesn’t use the same algorithm you can’t switch without going insecure.
> I don’t think this is an acceptable situation.

I agree that this is a factor that ought to be included in the process of deciding to move vendors. If your proposed new vendor can't do what you want, then presumably you don't move there. While it's always possible to make mistakes, it's not at all clear to me that particular problem is something that needs protocol-level mitigations.

DNSSEC is normally part of a layered set of defences. In such an architecture relaxing one layer for a period in order to fix a problem or avoid a more complicated transition can be a perfectly acceptable answer. Going insecure for a short period in that context is not necessarily a cop-out; it could well be smart thinking.


Joe