Gavin, thanks for your comments. Nothing major or blocking here, but still some clarifying questions on my side.
Inline replies: On Fri, Jul 12, 2024 at 4:41 AM Gavin Brown <gavin.br...@icann.org> wrote: > Hi Orie, comments below. > > > On 1 Jul 2024, at 23:30, Orie Steele <orie@transmute.industries> wrote: > > > > # Orie Steele, ART AD, comments for draft-ietf-regext-epp-ttl-14 > > CC @OR13 > > > > > https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-regext-epp-ttl-14.txt&submitcheck=True > [author-tools.ietf.org] > > > > Thanks to Anthony Somerset for the DNSDir early review. > > Thanks to Andy Newton for the shepherd writeup. > > Thanks to Gavin and the working group for this document. > > > > As you read my comments, please keep in mind that I am not a DNS expert. > > > > ## Comments > > > > I found the document easy to read, and most of my comments are minor. > > I do have a concern regarding the choice of enabling 2 modes "Default" > and "Policy". > > Especially after reading SAC-025, I wonder why the "Default" mode is > offered to implementations. > > If it is possible to make Policy Mode the only option, it seems like > that might improve the ability to surface and address the security issues > associated with short and long lived TTLs. > > > > ### Recommended default TTL? > > > > ``` > > 204 4. "default", which MUST NOT be present in command frames but MAY > be > > 205 present in response frames (see Section 2.1.1), and which is > used > > 206 by the server to indicate the default value; > > ``` > > > > ``` > > 224 2. empty, in which case the server's default TTL for the given > > 225 record type is to be applied. > > ``` > > > > Is there a recommended default TTL when EPP is used? > > > > See security considerations for why this might be a good idea. > > I don't think it would be appropriate for this draft to recommend a > default TTL value. The provisioning system should reflect the policy that's > determined on the publication side, not impose a policy on it. > That makes sense. > > > ### DELEG as example > > > > ``` > > 298 <ttl:ttl > > 299 for="custom" > > 300 custom="DELEG">3600<ttl:ttl> > > ``` > > > > Consider a record that is already registered with IANA, TLSA for example. > > As I understand it, TLSA is not appropriate for publication at a > delegation point, so using TLSA here would not make any more sense than > DELEG. Perhaps this should just be some placeholder value, such as > MYCUSTOMTYPE? > Elsewhere in the document it states the record must be registered, so providing an example that is registered seems better than a placeholder value for an example. I don't have strong opinions on this, but I think DELEG is not a good choice, because it is a work in progress. > > > ### Are 2 modes really needed? > > > > ``` > > 308 It has a single OPTIONAL policy attribute, which takes a boolean > > 309 value with a default value of false. > > ``` > > > > Should this be interpreted as Default Mode is mandatory to support and > Policy Mode is optional? > > No. The text extract only describes the permitted XML syntax of the > extension elements. > > By default, an <info> command just returns information about the specified > object. The purpose of the <info> Policy Mode is to allow the client to > also determine the server policy, that is, the supported DNS record types > and the corresponding min, default and max TTL values. > Is it the case that servers always have a policy, but that it is just not always requested? If servers don't have a policy but one is requested an error is produced? I'm imagining an implementer who might just prefer to implement one solution, 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, am I wrong about that? > > > ### Examples for Section 2.2.1 and 2.2.2 > > > > Examples in Section 2.2.1 and 2.2.2 both only include the Default Mode. > > > > Is Policy Mode supported by `<create>` and `<update>` ? > > > > I assume the answer is yes, but explicit examples might make this > clearer. > > No, <info> only. In the document, Default Mode and Policy Mode are only > specified in the context of the <info> command. > I see... mutations are only setting the ttl value, and the responses never include the policy information. > > > ``` > > 753 Servers MAY restrict the supported DNS record types in accordance > > 754 with their own policy. For example, a server MAY allow clients to > > 755 specify TTL values for DS records only. > > ``` > > > > Can this be strengthened to a SHOULD or MUST? > > Yes, a SHOULD here makes sense. > > > ### Range and Record Type Errors > > > > ``` > > 757 A server which receives a <create> or <update> command which > includes > > 758 a restricted record type MUST respond with a 2306 "Parameter value > > 759 policy" error. > > ``` > > > > Is it correct to reply with 2306 for both out of range and restricted > record type errors? > > No - 2306 is appropriate for an unsupported DNS record type, but 2004 > (Parameter value range error) is appropriate for "out of range" errors. > > There are a couple of usages of 2306 in Section 2.2 which should be 2004, > so I will fix those. > > > ### Servers can ignore clients? > > > > ``` > > 767 EPP servers which implement this extension SHOULD use the values > > 768 provided by EPP clients for the TTL values records published in the > > 769 DNS for domain and (if supported) host objects. > > ``` > > > > This feels like a throwaway sentence, why not MUST? > > > > When can this SHOULD be ignored? > > I didn't use MUST here because provisioning and publication systems are > normally loosely coupled, so MUST seemed (in my view) to impose too strong > an obligation on the server. There are scenarios where the TTLs might be > ignored, such as those contemplated in Section 4. > These sections are close enough to each other it is probably fine to leave this as is. > > ### When can servers ignore the host attribute? > > > > ``` > > 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 publishing > > 773 NS, A and AAAA records derived from host attributes. > > ``` > > > > When can this SHOULD be ignored? Why not MUST? > > This is basically saying the same thing as the preceding paragraph, just > 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. > Thanks, this took a few readings for me to understand, the reason this is not a MUST is the same. You may consider adding a sentence at the end to tie both of these SHOULDs to section 4, like: Regardless of if "host attributes" or "host objects" are in use, Section 4 explains that TTL values can change out of band. This is probably obvious to people with more experience with EPP though. > > ### Operational considerations > > > > ``` > > 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. > > ``` > > > > Is this a recommendation? Can it be turned into one or removed? > > It's not a recommendation, just a description of historical practice. It > could be removed. > This reads to me as a recommendation, if you are not trying to recommend implementers continue this trend, I suggest removing it. > > > ``` > > 800 Registry operators SHOULD implement limits on the maximum and > minimum > > 801 accepted TTL values that are narrower than the values permitted in > > 802 the XML schema in the Formal syntax (which were chosen to allow any > > 803 TTL permitted in DNS records), in order to prevent scenarios where > an > > 804 excessively high or low TTL causes operational issues on either > side > > 805 of the zone cut. > > ``` > > > > This feels like it is in conflict with the Default Mode, which is > mandatory to support? > > This is not correct. "Default Mode" provides clients with a way to > discover the current TTL settings for an object (as opposed to "Policy > Mode" which also returns the server policy, see above). These two modes, > which only apply 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. > Does this sentence imply then that there always exists a server policy, even if it's not requested in the info command? > > ### Should ensure user understands > > > > ``` > > 814 A common operational mistake is changing of DNS record TTLs during > or > > 815 after the planned change to the records themselves. This arises > due > > 816 to a misunderstanding about how TTLs work. > > > > 818 Implementations of this specification SHOULD ensure that the user > > 819 understands that changes to a TTL are only effective in shortening > > 820 transition periods if implemented a period of time — at least equal > > 821 to the current TTL — _before_ the planned change. The latency > > 822 between receipt of the <update> command and the actual publication > of > > 823 the changes in the DNS should also be taken into consideration in > > 824 this calculation. > > ``` > > > > I think this could be rephrased to use BCP14 language in a more > intuitive way: > > > > ``` > > It is RECOMMENDED that guidance be provided to users so that they are > aware that ... > > ``` > > Noted, I will make this change. > > > ### fast flux DNS > > > > ``` > > 828 Some malicious actors use a technique called "fast flux DNS" > > 829 ([SAC-025]) to rapidly change the DNS configuration for a zone in > > 830 order to evade takedown and law enforcement activity. > > > > 832 Registry operators should take this into consideration when setting > > 833 the lower limit on TTL values, since a short TTL on delegations may > > 834 enhance the effectiveness of fast flux techniques on evasion. > > ``` > > > > Consider shortening the first part to "in order to evade identification". > > I don't believe fast flux allows a malicious actor to evade > *identification*, its purpose is to render traditional takedown activities > moot, because the domain has already moved onto new infrastructure by the > time the old infrastructure has been disrupted. > The introduction of SAC-025 states: "Fast flux" is an evasion technique that cyber-criminals and Internet miscreants use to evade identification and to frustrate law enforcement and anticrime efforts aimed at locating and shutting down web sites used for illegal purposes. But I agree with your comment regardless. > Please revise the second part to provide mitigation advice, based on the > reference: > > > > ``` > > Mitigations methods that are practiced today, but not uniformly, include: > > • Authenticate contacts before permitting changes to name server > configurations. > > • Implement measures to prevent automated (scripted) changes to name > server > > configurations. > > • Set a minimum allowed TTL (e.g., 30 minutes) that is long enough to > thwart the > > double flux element of fast flux hosting. > > • Implement or expand abuse monitoring systems to report excessive DNS > > configuration changes. > > • Publish and enforce a Universal Terms of Service agreement that > prohibits the use > > of a registered domain and hosting services (DNS, web, mail) to abet > illegal or > > objectionable activities (as enumerated in the agreement). > > > > .... > > > > • Rate-limit or (limit by number per hour/day/week) changes to name > servers > > associated with a registered domain name. Registries and registrars > already > > apply rate-limiting techniques on query-based WHOIS services to > discourage > > abuse. Determine a rate of change that (a) accommodates legitimate > applications > > of short TTLs for NS records in TLD zone files, (b) provides > investigators with a > > window of opportunity to track down the origin of updates and identify > bots, and > > (c) makes short TTLs less useful to fast flux attackers. > > > > • Separate "short TTL updates" from normal registration change > processing. > > Treat requests to set TTLs below a certain limit as special requests > that require > > some form of verification. > > ``` > > > > Some of these are not directly related to TTL / EPP... some are. > > Rather than copy-and-paste, I propose something like this: > > Client implementations which provide an interface for customers to > configure TTL values for domain names should consider implementing controls > to deter and mitigate abusive behaviour, such as those outlined in the > "Current and Possible Mitigation Alternatives" section of <xref > target="SAC-025"/>. > That works for me, I only pasted the excerpt here for folks reading the list. > > > ### additional security considerations for ttl > > > > 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. > > 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 > the DNS Directorate. > I see your point. The draft simply describes an extension to EPP which enables clients to manage TTL. Since you comment on the impact of choice of TTL value in security considerations in relation to fast flux, I wondered if you should comment on the choice of TTL and its impact on these topics. Seems fine to leave off these considerations since they are not specific to this EPP extension, but TTL in general. > > 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>
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
