From: Gavin Brown <gavin.brown@icann.org>
To: Orie Steele <orie@transmute.industries>
Thread-Topic: [regext] Re: [Ext] AD Evaluation: draft-ietf-regext-epp-ttl-14
Thread-Index: AQHazAZL5cvEIvhSc0CZ4v8KssxBibHzXK2AgADLs4CABBQ3gA==
Date: Mon, 15 Jul 2024 12:08:06 +0000
Message-ID: <C18BA7DD-5B55-4B07-A519-9361FDD5C76F@icann.org>
References: 
 <CAN8C-_+kxp+0+oFfeLJ26+HQYS=Qn9XmSTyOSDKU3_4aPxYYDw@mail.gmail.com>
 <B12C01D4-4605-4825-AD04-40CF5B8224D1@icann.org>
 <CAN8C-_+qJfEL5iTzcd4HQ_6PTzj0ZSH60dMcdRV6FcGuCzk+TA@mail.gmail.com>
In-Reply-To: 
 <CAN8C-_+qJfEL5iTzcd4HQ_6PTzj0ZSH60dMcdRV6FcGuCzk+TA@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <D0194586BF64ED4F83A769863BBCA0E8@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Message-ID-Hash: MRCASG6UPY2VUTFMNVRJUHJ3AKNORUJE
CC: Registration Protocols Extensions <regext@ietf.org>,
 "draft-ietf-regext-epp-ttl@ietf.org" <draft-ietf-regext-epp-ttl@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5Bregext=5D_Re=3A_=5BExt=5D_AD_Evaluation=3A_draft-ietf-regext-ep?=
	=?utf-8?q?p-ttl-14?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/regext/Y00FiMbK12q0i0rnSSUQJ9ubhpQ>

Hi Orie, comments below.

I will shortly publish a new version with the amendments discussed in this =
thread.

> On 12 Jul 2024, at 22:50, Orie Steele <orie@transmute.industries> wrote:
>=20
> Gavin, thanks for your comments.
>=20
> Nothing major or blocking here, but still some clarifying questions on my=
 side.
>=20
> Inline replies:

[snip]

> > > Consider a record that is already registered with IANA, TLSA for exam=
ple.
>=20
> > As I understand it, TLSA is not appropriate for publication at a delega=
tion point, so using TLSA here would not make any more sense than DELEG. Pe=
rhaps this should just be some placeholder value, such as MYCUSTOMTYPE?
>=20
> > Elsewhere in the document it states the record must be registered, so p=
roviding an example that is registered seems better than a placeholder valu=
e for an example.
>=20
> I don't have strong opinions on this, but I think DELEG is not a good cho=
ice, because it is a work in progress.

OK, I have settled on "NEWRRTYPE" and will use that.

> > ### Are 2 modes really needed?
> >=20
> > ```
> > 308   It has a single OPTIONAL policy attribute, which takes a boolean
> > 309   value with a default value of false.
> > ```
> >=20
> > Should this be interpreted as Default Mode is mandatory to support and =
Policy Mode is optional?
>=20
> No. The text extract only describes the permitted XML syntax of the exten=
sion elements.
>=20
> By default, an <info> command just returns information about the specifie=
d object. The purpose of the <info> Policy Mode is to allow the client to a=
lso determine the server policy, that is, the supported DNS record types an=
d the corresponding min, default and max TTL values.
>=20
> Is it the case that servers always have a policy, but that it is just not=
 always requested?

Yes, servers will always have a policy. Or rather, they will need to decide=
 what the values of the "min" and "max" attributes should be as part of the=
 implementation of this extension (the "default" TTL is whatever value is a=
lready used for a given record type).

> I'm imagining an implementer who might just prefer to implement one solut=
ion, and get back extra info which they ignore when they don't care.
> It feels like there could be a reduction in implementation burden here, a=
m I wrong about that?

Client implementers may well implement a "policy mode by default" approach,=
 that's their choice.

A previous version of this document included policy information in all <inf=
o> responses, but feedback from the WG was that it should only be included =
when specifically requested.

> > Is Policy Mode supported by `<create>` and `<update>` ?
> >=20
> > I assume the answer is yes, but explicit examples might make this clear=
er.
>=20
> No, <info> only. In the document, Default Mode and Policy Mode are only s=
pecified in the context of the <info> command.
>=20
> I see... mutations are only setting the ttl value, and the responses neve=
r include the policy information.

Correct.

> > > ### When can servers ignore the host attribute?
> > >=20
> > > ```
> > > 771   EPP servers that use the "host attribute" model SHOULD use any =
A and/
> > > 772   or AAAA TTL values specified for the domain object when publish=
ing
> > > 773   NS, A and AAAA records derived from host attributes.
> > > ```
> > >=20
> > > When can this SHOULD be ignored? Why not MUST?
>=20
> > This is basically saying the same thing as the preceding paragraph, jus=
t in the scenario where an EPP server uses host attributes rather than host=
 objects. See Section 1.1 of RFC 5731 for an explanation of the difference.
>=20
> Thanks, this took a few readings for me to understand, the reason this is=
 not a MUST is the same.
>=20
> You may consider adding a sentence at the end to tie both of these SHOULD=
s to section 4, like:
>=20
> Regardless of if "host attributes" or "host objects" are in use, Section =
4 explains that TTL values can change out of band.
>=20
> This is probably obvious to people with more experience with EPP though.

These paragraphs appear immediately before Section 4, so I am not sure addi=
ng something is needed.=20

> > ###  Operational considerations
> >=20
> > ```
> > 796   Historically, registry operators have used a global TTL value for=
 all
> > 797   delegations within their zones, which could then be tuned to an
> > 798   optimum value.
> > ```
> >=20
> > Is this a recommendation? Can it be turned into one or removed?
>=20
> It's not a recommendation, just a description of historical practice. It =
could be removed.
>=20
> This reads to me as a recommendation, if you are not trying to recommend =
implementers continue this trend, I suggest removing it.=20

Will do (or rather, have done).

> =20
> > ```
> > 800   Registry operators SHOULD implement limits on the maximum and min=
imum
> > 801   accepted TTL values that are narrower than the values permitted i=
n
> > 802   the XML schema in the Formal syntax (which were chosen to allow a=
ny
> > 803   TTL permitted in DNS records), in order to prevent scenarios wher=
e an
> > 804   excessively high or low TTL causes operational issues on either s=
ide
> > 805   of the zone cut.
> > ```
> >=20
> > This feels like it is in conflict with the Default Mode, which is manda=
tory to support?
>=20
> This is not correct. "Default Mode" provides clients with a way to discov=
er the current TTL settings for an object (as opposed to "Policy Mode" whic=
h also returns the server policy, see above). These two modes, which only a=
pply to the <info> command, are not intended to, and indeed cannot, effect =
the server's ability to implement its own policy in relation to TTL values.
>=20
> Does this sentence imply then that there always exists a server policy, e=
ven if it's not requested in the info command?

Yes, servers will always have a policy. Or rather, they will need to decide=
 what the values of the "min" and "max" attributes should be as part of the=
 implementation of this extension (the "default" TTL is whatever value is a=
lready used for a given record type).

> > > ### additional security considerations for ttl
> > >=20
> > > Consider commenting on the impact of TTL on DDoS.
> > > Consider commenting on the impact of TTL on DNS Spoofing.
> > > Consider commenting on the impact of TTL on DNS Cache Poisoning.
>=20
> > I don't believe this draft has any implications on these topics. If you=
 think it might, then I think I would want to get input from DNSOP and/or t=
he DNS Directorate.
>=20
> I see your point. The draft simply describes an extension to EPP which en=
ables clients to manage TTL.
>=20
> Since you comment on the impact of choice of TTL value in security consid=
erations in relation to fast flux, I wondered if you should comment on the =
choice of TTL and its impact on these topics.
>=20
> Seems fine to leave off these considerations since they are not specific =
to this EPP extension, but TTL in general.

Noted.

G.

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org