Re: [regext] CDS/CDNSKEY vs. EPP update prohibited

Michael Bauland <Michael.Bauland@knipp.de> Fri, 02 December 2022 13:54 UTC

Return-Path: <Michael.Bauland@knipp.de>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417BAC14F6E5 for <regext@ietfa.amsl.com>; Fri, 2 Dec 2022 05:54:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAl5C3urJJNA for <regext@ietfa.amsl.com>; Fri, 2 Dec 2022 05:54:46 -0800 (PST)
Received: from kmx5a.knipp.de (kmx5a.knipp.de [IPv6:2a01:5b0:0:29::63]) (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 E887FC14F5E0 for <regext@ietf.org>; Fri, 2 Dec 2022 05:54:45 -0800 (PST)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [IPv6:2a01:5b0:0:25::36]) by kmx5a.knipp.de (Postfix) with ESMTP id 4NNvZT2WYhz4v4D for <regext@ietf.org>; Fri, 2 Dec 2022 14:54:41 +0100 (CET)
Authentication-Results: kmx5a.knipp.de; dkim=none; spf=softfail (kmx5a.knipp.de: 2a01:5b0:0:25::36 is neither permitted nor denied by domain of Michael.Bauland@knipp.de) smtp.mailfrom=Michael.Bauland@knipp.de
Received: from [IPV6:2a01:5b0:0:25::69] (unknown [IPv6:2a01:5b0:0:25::69]) by hp9000.do.knipp.de (Postfix) with ESMTP id E2F0272972 for <regext@ietf.org>; Fri, 2 Dec 2022 14:54:40 +0100 (MEZ)
Message-ID: <03f1b413-60a4-ed38-c709-58c21eb83445@knipp.de>
Date: Fri, 02 Dec 2022 14:54:35 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0
Content-Language: en-GB
To: regext@ietf.org
References: <BA12A2A4-E92C-4F3A-BC03-3C879D27AE5B@verisign.com>
From: Michael Bauland <Michael.Bauland@knipp.de>
In-Reply-To: <BA12A2A4-E92C-4F3A-BC03-3C879D27AE5B@verisign.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Rspamd-Action: no action
X-Rspamd-Server: v1117
X-Rspamd-Queue-Id: 4NNvZT2WYhz4v4D
X-Spamd-Bar: /
X-Spamd-Result: default: False [-0.10 / 15.00]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8391, ipnet:2a01:5b0::/32, country:DE]; FROM_EQ_ENVFROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[regext@ietf.org]; R_SPF_SOFTFAIL(0.00)[~all]; LOCAL_WL_IP(0.00)[2a01:5b0:0:25::36]
X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: LOCAL_WL_IP
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/oYf0ARqx6oZTOSxPYlzb5NmtlF4>
Subject: Re: [regext] CDS/CDNSKEY vs. EPP update prohibited
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2022 13:54:50 -0000

Hi,

On 02.12.2022 14:07, Gould, James wrote:
> Michael,
> 
> The prohibited statuses apply to client requests, which matches Case 2.  The prohibited statuses can apply to client requests via multiple channels (e.g., EPP or Web UI).  The prohibited statuses don't apply to server actions (e.g., auto renew, transitioning RGP statuses).  Use of CDS/CDNSKEY records to signal a server-side change is an interesting case, where does posting CDS/CDNSKEY records represent a client request that is processed by the server asynchronously?  I view the CDS/CDNSKEY as a new operation (e.g., DNSSEC automation update), supported by IETF RFCs, that does not apply to the existing EPP prohibited statuses.  All domain changes come down to an update, but EPP included prohibited statuses on a per operation / command basis.
> 
> I would then define Case 3, where CDS/CDNSKEY records represent is a new client operation that does not apply to the existing EPP prohibited statuses.  If we did want to prohibit this new operation via EPP, then a new prohibited status would be warranted.

I tend to agree. Changing the DNSSEC data here is not an operation 
requested/initiated by the client (i.e., registrar), but it's something 
the server (registry) does, because it got triggered via the DNS. For 
this reason the clientUpdateProhibited flag should be ignored.

The RFC states:
"Requests to update the object (other than to remove this status) 
MUST be rejected."

The question is then, is the server looking for CDS records in the DNS a 
request? I don't think it is. It is the server carrying out some 
maintenance work (e.g., key rollover), admittedly for the registrant (or 
rather the registrant's DNS provider). Nevertheless, it's the server's 
decision, when and if a found CDS records leads to an update of the 
domain's DNSSEC data.

Cheers,

Michael


-- 
____________________________________________________________________
      |       |
      | knipp |            Knipp  Medien und Kommunikation GmbH
       -------                    Technologiepark
                                  Martin-Schmeisser-Weg 9
                                  44227 Dortmund
                                  Germany

      Dipl.-Informatiker          Fon:    +49 231 9703-0
                                  Fax:    +49 231 9703-200
      Dr. Michael Bauland         SIP:    Michael.Bauland@knipp.de
      Software Development        E-mail: Michael.Bauland@knipp.de

                                  Register Court:
                                  Amtsgericht Dortmund, HRB 13728

                                  Chief Executive Officers:
                                  Dietmar Knipp, Elmar Knipp