Applicant Information

Name of proposed service.

Public Suffix Domain - Domain-based Message Authentication, Reporting and Conformance

Provide a general description of the proposed service including the impact to external users and how it will be offered.

The PSD DMARC approach to security is something the registry would undertake at the TLD level and as such there is no offering. All NXDOMAINs will be automatically protected and SLDs without a DMARC record would have the PSD DMARC applied when mail service providers query the DNS for the record.

Provide a technical description of the proposed service.

Most PSD DMARC related processing is performed by email receivers. Email receivers which implement PSD DMARC will query DMARC records published by the registry for SLDs within that registry that do not publish their own DMARC. This is then used as an input into their email system to enforce that any email purporting to originate from them must not be delivered/rejected. DMARC records are DNS records of type TXT that are published in the _dmarc subdomain of the protected domain. The DMARC records will specify requested email handling policy for messages that fail DMARC checks and the reporting address for DMARC feedback. Details are specified by RFC 7489 Section 6.1 and Section 6.3 as modified by RFC 9091 Section 3.2. When the service is implemented, TXT records similar to the following will be published in _dmarc: $TLD: v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc_reports@nic.$TLD. Processing for email receivers that retrieve these records is defined in RFC 7489 and RFC 9091. Authorised content of the record is defined by the IANA DMARC Tag Registry: https://www.iana.org/assignments/dmarc-parameters/dmarc-parameters.xhtml#tag

If this proposed service has already been approved by ICANN org for any gTLD, identify and provide a link to the RSEP request for the same service that was most recently approved.

.bank .insurance Request: https://www.icann.org/en/system/files/files/rsep-2022058-bank-et-al-request-21oct22-en.pdf Contract language: https://itp.cdn.icann.org/en/files/registry-agreements/multiple/ftld-registry-services-amend-list-1-pdf-04-11-2022-en.pdf

Describe the benefits of the proposed service and who would benefit from the proposed service.

The benefits of the proposed service include, but are not limited to: 1. Registrants whose SLDs are not in the zone will be protected from phishing and other email-borne abuses purporting to originate from them. 2. Registrants whose SLDs are in the zone, but not properly protected with DMARC will be protected by the PSD DMARC at the top-level. 3. The registry will be protected reputationally as NXDOMAINs will be protected from phishing and other email-borne abuses purporting to originate from them. 4. Email receivers (e.g., Google, Microsoft, Yahoo!) will be armed with a means to reject (e.g. not deliver) email purporting to be from an SLD that does not have DMARC implemented.

If additional information should be considered with the description of the proposed service, elaborate or attach one or more file(s) below.

None

What effect, if any, will the proposed service have on the life cycle of domain names?

None

Does the proposed service alter the storage and input of Registry Data? If yes, please explain.

No

Explain how the proposed service will affect the throughput, response time, consistency or coherence of responses to Internet servers or end systems.

No impact

Have technical concerns been raised about the proposed service? If so, identify the concerns and describe how you intend to address those concerns.

RFC 9091 identifies both potential privacy and security considerations associated with PSD DMARC. The planned service addresses these considerations as follows: Privacy Considerations: RFC 9091 recommends that PSD DMARC deployment be limited to TLDs that either control domains for a single entity (e.g. brand TLDs) or to those which mandate that registrants implement DMARC for their domains. The service will be available to registries that meet these criteria. The registry will limit requested feedback to aggregate reports. Aggregate reports will be used for the purposes of abuse/threat detection, enforcing compliance with the DMARC requirement for SLDs and enhancing the overall security and stability of the registry. Aggregate reports do not contain inherent personal data since the information is not related to an individual and rather it’s the machine or device sending the email. Access to data from aggregate reports will be restricted to select staff and external consultants or vendors on a need-to-know basis as part of the registry overall security and data privacy safeguards associated with this function. The registry will not activate failure/forensic reports (i.e., RUF). However, as the registry service provider continues to engage in technical and policy discussions with the growing community of operators that have deployed or are considering deploying PSD DMARC, we may become aware of enhanced security and stability benefits associated with failure/forensic reports. Prior to any future activation of these reports, the registry services provider would provide notice and seek approval from ICANN. Security Considerations: The registry and registrants benefit from improved additional data on abuse/threats. Other RFC 9091 security considerations do not require mitigation at the registry level. Data received in feedback reports will be securely maintained and segregated from other business data to provide security and privacy protections for Registrant related data.

Describe the quality assurance plan and/or testing of the proposed service prior to deployment.

Nominet has operated these records on existing public suffix zones in a ccTLD environment. Any deployment of new records is managed in a change control environment with beta testing first.

Identify and list any relevant RFCs or White Papers on the proposed service and explain how those papers are relevant.

RFC9091

List the relevant contractual provisions impacted by the proposed service necessary for a Registry Operator to use this proposed registry service. This includes, but is not limited to, Consensus Policies, previously approved amendments or services, Reserved Names, and Rights Protection Mechanisms.

None

What effect, if any, will the proposed service have upon a Registry Operator in regard to the reporting of data to ICANN?

None

What effect, if any, will the proposed service have upon a Registry Operator in regard to Registration Data Directory Service (RDDS)?

None

A Registry Agreement (RA) amendment is required when the proposed service: (i) contradicts existing provisions in the RA or (ii) is not contemplated in the RA and, therefore, needs to be added to Exhibit A of the RA and/or as an appropriate addendum/appendix. If applicable, provide draft language (or a link to previously approved RA amendment language) describing the service to be used by a Registry Operator in an RA amendment if the proposed service is approved. If an RA amendment is not applicable, respond with “N/A” and provide a complete response to question 4.2.

None

If the proposed service is permissible under an existing provision of an ICANN Registry Agreement, identify the provision and provide rationale. If not applicable, respond with “N/A” and provide a complete response to question 4.1.

Public Suffix Domain - Domain-based Message Authentication, Reporting & Conformance Registry Operator may implement the Domain-based Message Authentication, Reporting & Conformance (“DMARC”) extension for Public Suffix Domains (“PSD”) in the TLD’s DNS service, as follows: (a) Registry Operator may activate, in the TLD’s DNS service, the ASCII label “_dmarc” as owner of a DNS resource record of type TXT, class IN, and RDATA defining a PSD DMARC policy (as described in RFC 9989, and its successor standards). (b) Registry Operator may enable the reception of Aggregate Reports (as defined in RFC 9990, and its successor standards) solely for the purposes of detecting abuse or threats, enforcing compliance with the DMARC requirement for domains under registration, and enhancing the overall security and stability of the TLD. (c) Registry Operator must not enable other types of reports (e.g., Failure Reports) defined in the DMARC standard (as defined in relevant RFCs). (d) Registry Operator must restrict access to data from Aggregate Reports to select staff of Registry Operator and external consultants or vendors on a need-to-know basis as part of Registry Operator's overall security and data privacy safeguards associated with this function. (e) Registry Operator must ensure that registrants are informed that this PSD DMARC service is enabled in the TLD before registrants complete registration.

Describe your consultations with the community, experts, and/or others. This can include, but is not limited to, the relevant community for a sponsored or community TLD, registrars or the registrar constituency, end users and/or registrants, or other constituency groups. What were the quantity, nature, and results of the consultations? How will the proposed service impact these groups? Which groups support or oppose this proposed service?

Nominet has implemented and operated these settings in customer public suffixes in ccTLD environments adding additional trust to the zones.

Would there be any intellectual property impact or considerations raised by the proposed service? If so, please describe them.

None

Does the proposed service contain intellectual property exclusive to you? If so, please describe them.

None

Provide any other relevant information to include with the request. If none, respond with “N/A.”

N/A

If additional information should be considered, elaborate or attach one or more file(s) below.

None