[regext] Re: [Ext] Secdir last call review of draft-ietf-regext-epp-ttl-15

[Orie Steele <[e-mail]>]

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 AM Gavin Brown <[e-mail]> 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 <[e-mail]>
> 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 client
> operators. However, the RDAP extension (see draft-brown-rdap-ttl-extension,
> 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 to
> 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-assigned
> 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=max, 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 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
> >  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
>
>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>