Return-Path: 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 65341C14CF0C for ; Mon, 16 Sep 2024 10:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 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, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=transmute.industries 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 IeHnZcXosqED for ; Mon, 16 Sep 2024 10:47:14 -0700 (PDT) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C201C151524 for ; Mon, 16 Sep 2024 10:47:14 -0700 (PDT) Received: by mail-pf1-x42a.google.com with SMTP id d2e1a72fcca58-7193010d386so2997272b3a.1 for ; Mon, 16 Sep 2024 10:47:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transmute.industries; s=google; t=1726508834; x=1727113634; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=aJAIOaMvHEhVdlTq4X0cd/UXhkrIJwAn/zfekIa3FF0=; b=RRWbNNNscHiNkh1xhCkvQjCLdmrj0sLtTBsLkuvBf4gadVtMqbOLR5i7A0IzKTkiOu fL9Vh9P4OXT3cy6ai4Enf2eYQN9/Ox6C+zgVqIFdrZNUuBieiCVKO2RJIhDZNz2/MAfU VrT1uLLA3/LP/p1xtTyhhgoOBF4/amOtTYaMtBIjOTunrTxnatGMIB3bUKA/I3wrhOWt G5rT5ufQ6Lr59memH1GiLamFaYPcHPgZQXR2qKyhdF1tshIoemRKbsshdSAx9eC1t/pF ERg5pQ3CAGdIXYF4TR2dxeFYnXd5+Jd/oGCbc/CL4Lv+BwtQUkOPk4jvZMYyaPlKyA7V zdPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726508834; x=1727113634; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=aJAIOaMvHEhVdlTq4X0cd/UXhkrIJwAn/zfekIa3FF0=; b=helZisZ7O+BVxS7mZDo2TJ54Vok3kwQBO8bayC0S0JI14nCWGYFzeDD3b5k7p0Ck3I j5h+gk6ipR40gZBvLesKj1AoJZjhldyRXCBwF7tHuW2P4whIF9k+CXgCH+Ss6PH3G71H 3ZFHby61h4XwX/NxIwqZ7yefymnVJytOrtbHOaHEDaMeXnPHS4e5MBEFiFFWyFS+TJtP fr79srnhMWjNtYRExniMMygxHidYv8iXL1iDmptXVS5CQHDsc2L9p9OtEqk+MDu6Mts2 btIwpwnyMN/gj3jDCBaN8l9P7gMauz9wmELNcwjOaTu6LlTVudpyp4WFyUUrX42OYvnJ QlpQ== X-Forwarded-Encrypted: i=1; AJvYcCViavz2/2kb+yky7mg5BNwMYQT/DFf8XZFmS3GJGXz5qQ/4NGn4O3TltdOvnnCOiigCgEKS1RQ=@ietf.org X-Gm-Message-State: AOJu0Yytr4+ey+ET02gnMq2lom5855kf6W7HYeMNPU69fnnE6aFDzmnq ze76eQStedU3bIuN0EXN/Jezds9yDpKnETrReljYxnAYwstZ5tsXuQeg+qI3EBHuHzZQKA00c5C ktTPNpZfKag8VMgh63LkqT8BKPGEc1LldrSmU5Q== X-Google-Smtp-Source: AGHT+IE+x0OhrCB2RAo9hIaxk9SHSpBXQpcUjaPYQG+4ZVMQXALMVj4jBaLWO0ZNTObhxwZF9UJhww6C3ZtL/nKgjcM= X-Received: by 2002:aa7:88d4:0:b0:70d:2693:d215 with SMTP id d2e1a72fcca58-71936a5e771mr18720434b3a.16.1726508833281; Mon, 16 Sep 2024 10:47:13 -0700 (PDT) MIME-Version: 1.0 References: <172368109802.1105358.10586154866409358806@dt-datatracker-6df4c9dcf5-t2x2k> <76830A89-543A-404E-9314-99F37B3BEB28@icann.org> In-Reply-To: <76830A89-543A-404E-9314-99F37B3BEB28@icann.org> From: Orie Steele Date: Mon, 16 Sep 2024 12:47:02 -0500 Message-ID: To: Gavin Brown Content-Type: multipart/alternative; boundary="000000000000b5b7d106224029f4" Message-ID-Hash: GQU26WBNBSHKQC2TYOBNPC4BBZ746HYK X-Message-ID-Hash: GQU26WBNBSHKQC2TYOBNPC4BBZ746HYK X-MailFrom: orie@transmute.industries X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-regext.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Wes Hardaker , "secdir@ietf.org" , "draft-ietf-regext-epp-ttl.all@ietf.org" , "last-call@ietf.org" , "regext@ietf.org" X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5Bregext=5D_Re=3A_=5BExt=5D_Secdir_last_call_review_of_draft-ietf?= =?utf-8?q?-regext-epp-ttl-15?= List-Id: Registration Protocols Extensions Working Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000b5b7d106224029f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Wes, Thanks for your review, I believe Gavin has addressed your comments, however he has also asked you some questions. Please let me know if you have further comments, I am preparing ballot text for this document. Regards, OS, ART AD On Mon, Sep 2, 2024 at 9:57=E2=80=AFAM Gavin Brown = wrote: > Hi Wes, apologies for the delay, I was on PTO. My responses below. > > > On 15 Aug 2024, at 01:18, Wes Hardaker via Datatracker > wrote: > > > > Reviewer: Wes Hardaker > > Review result: Has Nits > > > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. These comments were written primarily for the benefit of the > > security area directors. Document editors and WG chairs should treat > > these comments just like any other last call comments. > > > > A note about my background: I'm very familiar with the DNS, moderately > > with EPP concepts, and not an expert on XML. > > > > The summary of the review is: ready with a few minor comments/nits > > > > Over all: well written, clear and easy to read document. Thank you. > > > > The biggest issue: > > > > - Did the WG discuss whether or not a client should be able to check > > generally how long a server will make use of a new TTL value? It's > > clear that the server can change it at any point, but that makes it > > very hard for a client to actually manage their records in a way > > where the TTL change point can be ideally depended upon. If I'm > > rolling a key and desire a 4 hour TTL in order to do so properly, > > but the server decides to switch back to a longer one 2 hours later > > that's a real problem and will cause large issues operationally. > > That was not discussed explicitly. The document describes a policy > discovery mechanism (see Section 2.1.1.2) which allows clients to learnt > the min/default/max values, but it does not provide a way to discover > if/when a server might reset a non-default value. > > EPP would not be particularly well-suited to provide this information, as > the audience for such information would be much wider than just EPP clien= t > operators. However, the RDAP extension (see draft-brown-rdap-ttl-extensio= n, > which I plan to bring to regext once this document is published) does > provide a way for a registry to publish its policy in a way that is > discoverable for all interested parties, not just those who can connect t= o > its EPP server. > > > Furthermore, what if the policy changes after a client has set their > > value. So if I set it to 4 hours because the policy is 30 minutes > > to 12 hours and then shortly after I set my TTL the server decides > > the new minimum value is 24 hours, what happens? > > The document does not address this and therefore it would be up to the > server operator to decide. They might decide to clobber the client-assign= ed > value, or honour it temporarily or permanently. > > Policy changes will almost certainly only happen infrequently, and the > omission was intentional on my point. Do you feel it warrants some > discussion in the document? > > > Comments and Nits: > > > > - the introduction could use a few more words describing that this > > document really only is applying to parent/child relationships. > > EPP is only ever used in that specific context. To add clarity, I will > change "domain name provisioning system" in the first sentence of the > introduction to "domain name registry system" to avoid any confusion. > > > - In the bottom of 1.1 there is a discussion about the ttl prefix > > being used in examples. It would add some clarity to specifically > > talk about the name space reference that the string should actually > > point to, like the rest of the examples already do. > > The text in this section is boilerplate that is present in almost all > EPP-related RFCs, going back to RFC 3730. > > > - Section 1.2.1 says that elements MAY have the following > > attributes.... but the reality is that the following list contains a > > bunch of REQUIRED, MUST, MUST NOT and MAY requirements. I'd argue > > this MAY should actually be dropped and left to each of the > > sub-bullets for exactness instead. Something like "the following > > attributes, depending on whether it appears in a command or response > > frame, can appear:" > > I will downgrade the "MAY" to "may". > > > - I note that there is no generic statement about what to do when any > > required elements are missing. Specifically, servers should always > > return "2306 Parameter value policy" error when any required field > > is missing or invalid. This should probably be added in section 3 > > generically, where the rest of the section may be specifically > > stating specific cases but should otherwise be used as a generic > > error message. > > RFC 5730 provides the 2003 "Required parameter missing" error code. > > > - It's unclear if the min parameter is allowed to equal to the max > > parameter. It's clearly stated that default can be equal to min and > > max, but it would be nice to state clearly that min can, in fact, be > > equal to max as well. > > If a server policy set min=3Dmax, then only that value could ever be > specified, and this extension would serve no function. > > > - In 1.2.1.1 there is no upper bound on the TTL value, which surprises > > me. I think it should match the DNS spec and I think it's indicated > > it might be in the XML requirements (I didn't check). > > The schema sets the maximum. > > > - In general it seems that the common terminology of > > "registry/registrar/registrant" is avoided (which is fine by me) but > > there are a few instances (eg 1.2.1.2 bullet #3). I may be > > misreading the intention to shy away from this terminology though. > > I'll change "registry" to "server". > > > - I'd suggest moving the examples in 1.2.1.3 after the 1.3 section > > since the examples include a info reference (in 1.2.1.3.2). > > That makes sense, will do. > > > - I'd suggest tests that validate the XML if one is not already in plac= e. > > All XML instances are validated as part of the document generation worklo= w. > > > - In the XML the clID and crID are both frequently "ClientX" -- I wante= d > > to verify that this value is the right example value for both fields > > It's an arbitary string, but is used throughout the base RFC series and > many subsequent documents. > > > - I note the DELEG example reference in the 2.2.2, which made me smile > > (full disclosure: I was a DELEG BOF chair). > > DELEG was top of mind when making sure this extension was future-proof. > > > - You might mention in the security considerations that an account > > compromise would lead to an attacker changing the NS/glue addresses > > and then setting a max length TTL to keep the real client from a > > swift recovery. > > That's a good suggestion, thanks. > > I'll upload a new version shortly! > > G. > > -- > Gavin Brown > Principal Engineer, Global Domains & Strategy > Internet Corporation for Assigned Names and Numbers (ICANN) > > https://www.icann.org > > --=20 ORIE STEELE Chief Technology Officer www.transmute.industries --000000000000b5b7d106224029f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Wes,=C2=A0

Thanks for your review, I believe Gavin = has addressed your comments, however he has also asked you some questions.<= br>
Please let me know if you have further comments, I am preparing ball= ot text for this document.

Regards,

OS, ART AD

On Mon, Sep 2, = 2024 at 9:57=E2=80=AFAM Gavin Brown <gavin.brown@icann.org> wrote:
Hi Wes, apologies for the delay, I was on PTO. M= y responses below.

> On 15 Aug 2024, at 01:18, Wes Hardaker via Datatracker <noreply@ietf.org> wrote:<= br> >
> Reviewer: Wes Hardaker
> Review result: Has Nits
>
> I have reviewed this document as part of the security directorate'= s
> ongoing effort to review all IETF documents being processed by the
> IESG. These comments were written primarily for the benefit of the
> security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments.
>
> A note about my background: I'm very familiar with the DNS, modera= tely
> with EPP concepts, and not an expert on XML.
>
> The summary of the review is: ready with a few minor comments/nits
>
> Over all: well written, clear and easy to read document.=C2=A0 Thank y= ou.
>
> The biggest issue:
>
> - Did the WG discuss whether or not a client should be able to check >=C2=A0 generally how long a server will make use of a new TTL value?=C2= =A0 It's
>=C2=A0 clear that the server can change it at any point, but that makes= it
>=C2=A0 very hard for a client to actually manage their records in a way=
>=C2=A0 where the TTL change point can be ideally depended upon.=C2=A0 I= f I'm
>=C2=A0 rolling a key and desire a 4 hour TTL in order to do so properly= ,
>=C2=A0 but the server decides to switch back to a longer one 2 hours la= ter
>=C2=A0 that's a real problem and will cause large issues operationa= lly.

That was not discussed explicitly. The document describes a policy discover= y mechanism (see Section 2.1.1.2) which allows clients to learnt the min/de= fault/max values, but it does not provide a way to discover if/when a serve= r might reset a non-default value.

EPP would not be particularly well-suited to provide this information, as t= he audience for such information would be much wider than just EPP client o= perators. However, the RDAP extension (see draft-brown-rdap-ttl-extension, = which I plan to bring to regext once this document is published) does provi= de a way for a registry to publish its policy in a way that is discoverable= for all interested parties, not just those who can connect to its EPP serv= er.

>=C2=A0 Furthermore, what if the policy changes after a client has set t= heir
>=C2=A0 value.=C2=A0 So if I set it to 4 hours because the policy is 30 = minutes
>=C2=A0 to 12 hours and then shortly after I set my TTL the server decid= es
>=C2=A0 the new minimum value is 24 hours, what happens?

The document does not address this and therefore it would be up to the serv= er operator to decide. They might decide to clobber the client-assigned val= ue, or honour it temporarily or permanently.

Policy changes will almost certainly only happen infrequently, and the omis= sion was intentional on my point. Do you feel it warrants some discussion i= n the document?

> Comments and Nits:
>
> - the introduction could use a few more words describing that this
>=C2=A0 document really only is applying to parent/child relationships.<= br>
EPP is only ever used in that specific context. To add clarity, I will chan= ge "domain name provisioning system" in the first sentence of the= introduction to "domain name registry system" to avoid any confu= sion.

> - In the bottom of 1.1 there is a discussion about the ttl prefix
>=C2=A0 being used in examples.=C2=A0 It would add some clarity to speci= fically
>=C2=A0 talk about the name space reference that the string should actua= lly
>=C2=A0 point to, like the rest of the examples already do.

The text in this section is boilerplate that is present in almost all EPP-r= elated RFCs, going back to RFC 3730.

> - Section 1.2.1 says that elements MAY have the following
>=C2=A0 attributes.... but the reality is that the following list contai= ns a
>=C2=A0 bunch of REQUIRED, MUST, MUST NOT and MAY requirements.=C2=A0 I&= #39;d argue
>=C2=A0 this MAY should actually be dropped and left to each of the
>=C2=A0 sub-bullets for exactness instead.=C2=A0 Something like "th= e following
>=C2=A0 attributes, depending on whether it appears in a command or resp= onse
>=C2=A0 frame, can appear:"

I will downgrade the "MAY" to "may".

> - I note that there is no generic statement about what to do when any<= br> >=C2=A0 required elements are missing.=C2=A0 Specifically, servers shoul= d always
>=C2=A0 return "2306 Parameter value policy" error when any re= quired field
>=C2=A0 is missing or invalid.=C2=A0 This should probably be added in se= ction 3
>=C2=A0 generically, where the rest of the section may be specifically >=C2=A0 stating specific cases but should otherwise be used as a generic=
>=C2=A0 error message.

RFC 5730 provides the 2003 "Required parameter missing" error cod= e.

> - It's unclear if the min parameter is allowed to equal to the max=
>=C2=A0 parameter.=C2=A0 It's clearly stated that default can be equ= al to min and
>=C2=A0 max, but it would be nice to state clearly that min can, in fact= , be
>=C2=A0 equal to max as well.

If a server policy set min=3Dmax, then only that value could ever be specif= ied, and this extension would serve no function.

> - In 1.2.1.1 there is no upper bound on the TTL value, which surprises=
>=C2=A0 me.=C2=A0 I think it should match the DNS spec and I think it= 9;s indicated
>=C2=A0 it might be in the XML requirements (I didn't check).

The schema sets the maximum.

> - In general it seems that the common terminology of
>=C2=A0 "registry/registrar/registrant" is avoided (which is f= ine by me) but
>=C2=A0 there are a few instances (eg 1.2.1.2 bullet #3).=C2=A0 I may be=
>=C2=A0 misreading the intention to shy away from this terminology thoug= h.

I'll change "registry" to "server".

> - I'd suggest moving the examples in 1.2.1.3 after the 1.3 section=
>=C2=A0 since the examples include a info reference (in 1.2.1.3.2).

That makes sense, will do.

> - I'd suggest tests that validate the XML if one is not already in= place.

All XML instances are validated as part of the document generation worklow.=

> - In the XML the clID and crID are both frequently "ClientX"= -- I wanted
>=C2=A0 to verify that this value is the right example value for both fi= elds

It's an arbitary string, but is used throughout the base RFC series and= many subsequent documents.

> - I note the DELEG example reference in the 2.2.2, which made me smile=
>=C2=A0 (full disclosure: I was a DELEG BOF chair).

DELEG was top of mind when making sure this extension was future-proof.

> - You might mention in the security considerations that an account
>=C2=A0 compromise would lead to an attacker changing the NS/glue addres= ses
>=C2=A0 and then setting a max length TTL to keep the real client from a=
>=C2=A0 swift recovery.

That's a good suggestion, thanks.

I'll upload a new version shortly!

G.

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

http= s://www.icann.org



--
--000000000000b5b7d106224029f4--