Re: [DNSOP] DNSSEC Strict Mode

Ben Schwartz <bemasc@google.com> Tue, 23 February 2021 16:16 UTC

Return-Path: <bemasc@google.com>
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 38DCF3A2D76 for <dnsop@ietfa.amsl.com>; Tue, 23 Feb 2021 08:16:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 vay4oimk8zlJ for <dnsop@ietfa.amsl.com>; Tue, 23 Feb 2021 08:16:11 -0800 (PST)
Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 4AD183A2D59 for <dnsop@ietf.org>; Tue, 23 Feb 2021 08:16:11 -0800 (PST)
Received: by mail-il1-x12d.google.com with SMTP id e2so14607022ilu.0 for <dnsop@ietf.org>; Tue, 23 Feb 2021 08:16:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mZbJipRdFAFsEm2P/WDWsHA5wqwPUQ6Tzolpa8UfWbw=; b=pDMOERcAYL69Wymr+Nx9zDH95K+Z0Wm8Y2gQSDo8FJzUpAj1Q78YYley15hszG0yWe 38jiX7+mzx5ZuAY37QXFblbdWRCbv2W84Rjib7nHIYkPaXySg2Tp0k7iy554/5786J5G MJStYnlWDLhnyfHjjuZbtGu6QDs7m27vEXdAvOzOY/2tWb2PkvCsHF6QEp9it7qPTTVv CfIvHLsW/PJ+/SMe2rculNiOMisFzumVECt0FpMbfmsRDXcp1ejD/VKtFaC40NzXhuNg DOnpDQRmuNk00jfOqHIIGIcPIPZ82dVo8HY6Wpj8FgyvOWUbLZ0xwwj7AX1ZYtz87EJu Q2KA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mZbJipRdFAFsEm2P/WDWsHA5wqwPUQ6Tzolpa8UfWbw=; b=jYYHMI1gQjcMudGz9Zc2BrVu8CjSOye1RBcOE/WFpNrmjDg4i4NviFwHz5U+1aCs8l FdV38WST5vl0EZecoL/Z9HDLYIqDepBoMt77agiaq0ikTOJbE+EJ8E45wo2VU52miRuv v5smXi1B38vPVAGxYGu+/sczq6GqdrqhXg3nk05opttxOcISbx74BoS7wZ6AYzTTUzQp V8bLsYV1Mb/UHTSAh71SXF0H6JGEJXvnJJ3i+iUS0J4SEZROmvyC3Bqo48MgFGZM3KG4 iBpaWBjM9hkgTh8Ly8IQfXO/du0Kko4gXqlP3B0EDwPYuXB4b9B2gOdGLMZIfy8YaKH8 L48w==
X-Gm-Message-State: AOAM532snk3e2Bfz2nQC4i+DQbfQ37UERW2BGN2vU8/iH/DkoqRq7PXc QuNcHEUZfB25UqN3KzVEQKNOyuKtQfy/nSYfyNtRqm4/4N0=
X-Google-Smtp-Source: ABdhPJz7LuUdvf8jplo4ytg1I7/MfTgwuS/y8oXrXDhUMDeZeQk+9Z66uGq4DeyCDvKgAo0sbck1eI4xux2p/tWY5So=
X-Received: by 2002:a05:6e02:13a5:: with SMTP id h5mr19937875ilo.263.1614096970222; Tue, 23 Feb 2021 08:16:10 -0800 (PST)
MIME-Version: 1.0
References: <CAHbrMsBeCiZ-31hjKvet2UPDPFhdVYpgqR6Kw-WWz1ERgeSFoQ@mail.gmail.com> <573d208d-d3aa-cf8-c9bb-7737b7fe9170@nohats.ca>
In-Reply-To: <573d208d-d3aa-cf8-c9bb-7737b7fe9170@nohats.ca>
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 23 Feb 2021 11:15:58 -0500
Message-ID: <CAHbrMsCy-gWxT=iEbibDKZ_7zexLncTVaO4DtctybtX2jSo5cA@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="00000000000091d58805bc033c9f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/zNKIvXEk06xDiMDf6XSF4atmNvo>
Subject: Re: [DNSOP] 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: Tue, 23 Feb 2021 16:16:13 -0000

On Tue, Feb 23, 2021 at 10:41 AM Paul Wouters <paul@nohats.ca> wrote:

> On Tue, 23 Feb 2021, Ben Schwartz wrote:
>
> > Inspired by some recent discussions here (and at DNS-OARC), and hastened
> by the draft cut-off, I present for your consideration "DNSSEC Strict
> > Mode":
> https://datatracker.ietf.org/doc/html/draft-schwartz-dnsop-dnssec-strict-mode-00
> > Abstract:
> > Currently, the DNSSEC security of a zone is limited by the strength of
> its weakest signature algorithm.  DNSSEC Strict Mode makes zones as secure
> as their strongest
> > algorithm instead.
>
> But why is that a problem? I assume that:
>
> 1) A regular zone has 1 algorithm
> 2) If there are two algorithms, the zone is moving from one to another
> 3) Accepting the outgoing algorithm during the migration is basically
> harmless
>
> Am I making a wrong assumption here?
>

I can't claim that your assumptions are wrong, but they're different from
mine.  I am assuming, in this draft, that there may be some valid reasons
to have a zone persistently signed by multiple algorithms.  The
introduction lists three such reasons, all variations on "because I have to
add an algorithm that I don't totally trust".  That could be because some
validators (perhaps including specific partners or customers) don't support
my favorite algorithm, or because there is no single algorithm that seems
totally trustworthy to me.

This gets more complicated with size and performance considerations.  For
example, a zone might wish to remain compatible with RSA-only validators
but feel that RSA-N keys are too big.  In that case, they could sign with
RSA-N/2 and (stronger, smaller) ECDSA keys.  Currently, this is not a good
option: a zone in that configuration would be weaker than if it were only
signed with RSA-N/2.

Also, we went out of our way to avoid specifying which algorithm is
> "weaker" or "stronger" for good reasons, as people will disagree on
> this, but the code path has to put something in.


Note that nothing in this draft involves any software with opinions about
"weaker" and "stronger" algorithms.  The zone owner marks certain
algorithms (ideally all algorithms in use) as Strict, and the validator
checks that they all work.


> Better not to have
> this assumption baked in at all. Case in point, harden-algo-downgrade: yes
> in unbound deems ecdsap256sha256 to be a downgrade from rsasha256.
>
> Paul
>