Re: [DNSOP] [Ext] DNSSEC Strict Mode

"libor.peltan" <libor.peltan@nic.cz> Thu, 25 February 2021 07:58 UTC

Return-Path: <libor.peltan@nic.cz>
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 840243A151A for <dnsop@ietfa.amsl.com>; Wed, 24 Feb 2021 23:58:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 BE3IOwYKHfhe for <dnsop@ietfa.amsl.com>; Wed, 24 Feb 2021 23:58:42 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 7FA1F3A1518 for <dnsop@ietf.org>; Wed, 24 Feb 2021 23:58:41 -0800 (PST)
Received: from [192.168.0.105] (mem-185.47.220.208.jmnet.cz [185.47.220.208]) by mail.nic.cz (Postfix) with ESMTPSA id 4DA2C1405AF; Thu, 25 Feb 2021 08:58:39 +0100 (CET)
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>, Brian Dickson <brian.peter.dickson@gmail.com>
Cc: dnsop <dnsop@ietf.org>, Samuel Weiler <weiler@watson.org>, Paul Hoffman <paul.hoffman@icann.org>, Ulrich Wisser <ulrich@wisser.se>
References: <CAHbrMsBeCiZ-31hjKvet2UPDPFhdVYpgqR6Kw-WWz1ERgeSFoQ@mail.gmail.com> <7BB07063-2CA3-4283-8866-2B19A7AAA9A0@icann.org> <45e3c45-d324-8124-5dae-98acba9dd7cb@watson.org> <CAHbrMsBsG8OnXOXwAFY5eNf-0viQ_e5nKKhp1XVpnpMkGW1L-Q@mail.gmail.com> <02CAFAF2-BD58-48D4-B9CC-DD06EB99357B@wisser.se> <57BA9FA0-C16D-4178-B4A8-C9D9B174AC82@isc.org> <CAHbrMsBjOmKXmv7vJoCB+horzmzHDkn3KYPbNxeyB3miWLV2WA@mail.gmail.com> <CAH1iCipf1gD0s_5y470gGyiSJS6+BeAEtVM_PP2okz=iaNvyig@mail.gmail.com> <CAHbrMsAcwancick4-XWL_wQgFEtyQZ5XO71aTO+gZNdXWbYsCQ@mail.gmail.com>
From: "libor.peltan" <libor.peltan@nic.cz>
Message-ID: <4ac1fc4c-11ce-a88f-3273-259dce5bf9c2@nic.cz>
Date: Thu, 25 Feb 2021 08:58:38 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <CAHbrMsAcwancick4-XWL_wQgFEtyQZ5XO71aTO+gZNdXWbYsCQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------A316C64C0DF3D05EDF66800C"
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.102.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/i5_v-7jyxRdTO168fTyC9Mli1rM>
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 07:58:45 -0000

Hi Ben,

Dne 25. 02. 21 v 1:50 Ben Schwartz napsal(a):
>
>
> On Wed, Feb 24, 2021 at 6:57 PM Brian Dickson 
> <brian.peter.dickson@gmail.com <mailto:brian.peter.dickson@gmail.com>> 
> wrote:
>
>
>     That's not possible. The DS records are on the parent side (TLD)
>     and the TTL is set by the TLD per whatever their standard policy
>     is. Same for RRSIGs over those DS records.
>
>
> That's fine.  I meant the TTLs of the ZSKs and zone contents.  
> Switching from provider A to provider B, the sequence would be
> 1. Set all TTLs in the zone to zero
> 2. Wait
> 3. Copy zone to provider B
> 4. Add DS for B's keys to the parent

This wouldn't work as well. The resolver would see two DSs with 
different algorithms at the parent zone, but only one (pair of) DNSKEYs 
with single algorithm, whichever provider of your zone it'll query.

This would violate RFC 4035: "The apex DNSKEY RRset itself MUST be 
signed by each algorithm appearing in the DS RRset located at the 
delegating parent (if any)."

> 5. Wait
> 6. Add B's NS to the parent
> 7. Remove A's NS from the parent
> 8. Wait
> 9. Remove DS for A's keys from the parent
> 10. Set zone TTLs to > 0

IMHO, performing an algorithm rollover while switching DNSSEC providers 
is indeed difficult, if possible at all. Even the lax validation doesn't 
help much.

However, performing an algorithm rollover normally isn't that hard using 
proper tooling, so I don't think we should continue to justify lax 
validation only in order to encourage signers to switch from using 
obsolete algorithms.

Libor

>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop