Skip to main content

EPP Pre-Registration Verification
draft-latour-pre-registration-00

Document Type Active Internet-Draft (individual)
Authors Jacques Latour , Don Slaunwhite , Tim Johnson
Last updated 2023-11-15
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-latour-pre-registration-00
Network Working Group                                          J. Latour
Internet-Draft                                             D. Slaunwhite
Intended status: Standards Track                                    CIRA
Expires: 18 May 2024                                          T. Johnson
                                                              InternetNZ
                                                        15 November 2023

                   EPP Pre-Registration Verification
                    draft-latour-pre-registration-00

Abstract

   This Internet Draft introduces an extension to the Extensible
   Provisioning Protocol (EPP) for top-level domain (TLD) registries,
   enabling registrars to submit pre-registration information for domain
   names.  The extension facilitates quality verification by the
   registry, employing advanced Artificial Intelligence and Machine
   Learning (AI/ML) techniques.  Pre-registrations are assigned a
   quality score based on the analysis of the submitted data, ranging
   from 0 for non-abusive registrations to 100 for potentially abusive
   ones.  This extension addresses the critical need to proactively
   identify and mitigate abusive domain registrations within TLDs,
   contributing to a safer and more reliable internet environment.  The
   document outlines the EPP command definitions, XML schemas, data
   flow, and security considerations necessary to implement this
   innovative quality assurance mechanism, thereby enhancing the
   integrity and trustworthiness of TLD registrations.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://CIRALabs.github.com/CIRALabs/epp-pre-registration-
   verification/draft-latour-pre-registration.html.  Status information
   for this document may be found at https://datatracker.ietf.org/doc/
   draft-latour-pre-registration/.

   Discussion of this document takes place on the WG Working Group
   mailing list (mailto:WG@example.com).

   Source for this draft and an issue tracker can be found at
   https://github.com/CIRALabs/epp-pre-registration-verification.

Latour, et al.             Expires 18 May 2024                  [Page 1]
Internet-Draft      EPP Pre-Registration Verification      November 2023

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 18 May 2024.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Importance and Benefits . . . . . . . . . . . . . . . . .   4
     1.3.  Scope of the Extension - Verification . . . . . . . . . .   4
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Extension Overview and Command Definition . . . . . . . . . .   5
     4.1.  Extension Overview  . . . . . . . . . . . . . . . . . . .   5
       4.1.1.  EPP Protocol Extension Purpose  . . . . . . . . . . .   5
       4.1.2.  Integration with AI/ML Techniques . . . . . . . . . .   6
   5.  EPP Command Definition  . . . . . . . . . . . . . . . . . . .   6
     5.1.  New EPP Commands  . . . . . . . . . . . . . . . . . . . .   6
     5.2.  XML Schema Definitions  . . . . . . . . . . . . . . . . .   6
   6.  EPP Protocol Extension  . . . . . . . . . . . . . . . . . . .   7

Latour, et al.             Expires 18 May 2024                  [Page 2]
Internet-Draft      EPP Pre-Registration Verification      November 2023

     6.1.  Extended "create" Command for Pre-Registration and Quality
           Verification  . . . . . . . . . . . . . . . . . . . . . .   7
       6.1.1.  Command Name  . . . . . . . . . . . . . . . . . . . .   7
       6.1.2.  Command Purpose . . . . . . . . . . . . . . . . . . .   7
       6.1.3.  XML Element Extension . . . . . . . . . . . . . . . .   7
       6.1.4.  Usage . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.2.  Introduction of New Verify EPP Commands . . . . . . . . .   8
     6.3.  Command Flow Overview . . . . . . . . . . . . . . . . . .   9
   7.  Pre-Registration and Verification Command Flow  . . . . . . .   9
     7.1.  Pre-Registration Data Submission Flow . . . . . . . . . .   9
     7.2.  Quality Verification Flow . . . . . . . . . . . . . . . .   9
   8.  Pre-Registration Quality Score *_Guidance_* . . . . . . . . .  10
     8.1.  Score 0 - 20 (Non-Abusive): . . . . . . . . . . . . . . .  10
       8.1.1.  Actionable Actions: . . . . . . . . . . . . . . . . .  10
     8.2.  Score 21 - 40 (Low Suspicion):  . . . . . . . . . . . . .  11
       8.2.1.  Actionable Actions: . . . . . . . . . . . . . . . . .  11
     8.3.  Score 41 - 60 (Moderate Suspicion): . . . . . . . . . . .  11
     8.4.  Actionable Actions: . . . . . . . . . . . . . . . . . . .  11
     8.5.  Score 61 - 80 (High Suspicion): . . . . . . . . . . . . .  11
       8.5.1.  Actionable Actions: . . . . . . . . . . . . . . . . .  11
     8.6.  Score 81 - 99 (Very High Suspicion):  . . . . . . . . . .  11
       8.6.1.  Actionable Actions: . . . . . . . . . . . . . . . . .  11
     8.7.  Score 100 (Absolutely Malicious): . . . . . . . . . . . .  12
       8.7.1.  Actionable Actions: . . . . . . . . . . . . . . . . .  12
     8.8.  Error Handling  . . . . . . . . . . . . . . . . . . . . .  12
     8.9.  Registration Timing Considerations  . . . . . . . . . . .  12
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   11. Normative References  . . . . . . . . . . . . . . . . . . . .  12
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

1.1.  Problem Statement

   The current EPP protocol lacks mechanisms for registrars to submit
   pre-registration data to the registry for quality verification.  This
   gap leads to potential issues with abusive domain registrations,
   which can harm the integrity of the top-level domain (TLD). ## Use
   Case Description

Latour, et al.             Expires 18 May 2024                  [Page 3]
Internet-Draft      EPP Pre-Registration Verification      November 2023

   A registrant wants to register domain names within a TLD registry via
   a registrar.  To ensure the quality of registrations and prevent
   abusive domains, the registrar uses the proposed EPP extension to
   submit pre-registration data of the registrant to the registry.  The
   registry, equipped with AI/ML techniques or services, analyzes this
   data to assign a registrant quality score back to the registrar.
   Based on this score, the registrar can decide whether to accept,
   reject or put on hold the registration request.

1.2.  Importance and Benefits

   Addressing the quality of the registrant data before the actual
   registration process occurs brings many benefits.  Adding a pre-
   registration process benefits the domain registration ecosystem by: -
   Potentially reducing the number of malicious registration and frauds
   and reducing operating costs to registrar and registry in responding
   to the abuse. - Ensuring the quality of domain registrations is
   crucial to maintaining the trust and reputation of the TLD.  Abusive
   registrations can lead to various issues, including spam, phishing,
   and other malicious activities. - The proposed extension enables
   registries to proactively identify and block abusive registrations,
   thereby improving the overall quality of domain names within the TLD.
   This can lead to a safer and more reliable internet for end-users. -
   And contributing to a safer internet.

1.3.  Scope of the Extension - Verification

   This EPP extension focuses on enabling registrars to submit pre-
   registration data to the registry and receive a registrant quality
   score based on abuse AI/ML analysis.  It does not address other
   aspects of domain registration, such as pricing or dispute
   resolution.

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Latour, et al.             Expires 18 May 2024                  [Page 4]
Internet-Draft      EPP Pre-Registration Verification      November 2023

3.  Terminology

   *Pre-Registration Registrant Information*: This term refers to the
   data and details submitted by the registrar before the registration
   of a domain name.  It typically includes information provided by the
   registrant, such as contact information and the intended use of the
   domain name, and is used for quality verification by the registry as
   part of the pre-registration process.

   *Registrant*: RFC8499 defines the registrant as "an individual or
   organization on whose behalf a name in a zone is registered by the
   registry.  A registrant is created in the registry after a successful
   registration with the registrar.

   *AI/ML-Powered Domain Abuse Mitigation*: This term encompasses the
   use of Artificial Intelligence (AI) and Machine Learning (ML)
   technologies within the top-level domain (TLD) industry to identify,
   prevent, and mitigate abusive domain registrations.  These
   technologies are employed to detect and combat various forms of
   domain abuse, such as spam, phishing, malware distribution, and other
   malicious activities, ultimately enhancing the security and integrity
   of domain name space.

   *Quality Score*: Define a quality score as the numeric value assigned
   to a pre-registration registrant based on the AI/ML analysis of their
   pre-registration data.  Mention that higher scores indicate
   potentially abusive registrations.

   *EPP*: RFC 5730: Extensible Provisioning Protocol (EPP) (rfc-
   editor.org)

4.  Extension Overview and Command Definition

4.1.  Extension Overview

4.1.1.  EPP Protocol Extension Purpose

   This extension is designed to enhance the Extensible Provisioning
   Protocol (EPP) by introducing mechanisms for registrars to submit
   pre-registration information to the registry, thus enabling the
   verification of the quality of domain name registrations using
   advanced Artificial Intelligence and Machine Learning (AI/ML)
   techniques.  The primary objectives of this extension are as follows:

   *  Quality Assurance: To proactively assess the quality of domain
      name registrations and reduce the risk of abusive registrations
      within the top-level domain (TLD).

Latour, et al.             Expires 18 May 2024                  [Page 5]
Internet-Draft      EPP Pre-Registration Verification      November 2023

   *  Enhanced Trust: To improve the overall quality of domain names
      within the TLD, promoting a safer and more trustworthy internet
      environment.

4.1.2.  Integration with AI/ML Techniques

   The extension integrates AI/ML techniques into the EPP framework,
   allowing the registry to analyze pre-registration data for signs of
   potential abuse.  These techniques include data analysis, pattern
   recognition, and predictive modeling.  The analysis results in a
   registrant quality score, which helps the registry make informed
   decisions regarding the acceptance or rejection of registration
   requests.

5.  EPP Command Definition

5.1.  New EPP Commands

   This extension introduces new EPP commands to facilitate pre-
   registration data submission and quality verification.  The following
   commands are defined within the extension: ### "create" Command
   Extension Command Name: "create" (Extended) Purpose: To create a new
   domain registration while including additional XML elements for
   registrars to submit pre-registration data.  Registrars can provide
   information such as the intended use of the domain and other relevant
   details.  XML Element: <pre-registration-data> - This element
   encapsulates the pre-registration data submitted by the registrar.
   Usage: Registrars initiate the "create" command with the pre-
   registration data, which is then stored by the registry for later
   analysis. ### "verify" Command

   Command Name: "verify" (New) Purpose: To trigger the quality
   verification process for pre-registration data that has been
   submitted.  Registrars can initiate this command after an initial
   "create" request.  XML Element: N/A Usage: After pre-registration
   data is submitted through the "create" command, registrars can use
   the "verify" command to request the registry's AI/ML analysis and
   obtain a registrant quality score.

5.2.  XML Schema Definitions

   To support these new EPP commands, the extension defines the XML
   schema elements necessary for encapsulating pre-registration data,
   ensuring interoperability between EPP clients and servers.

   TBD

Latour, et al.             Expires 18 May 2024                  [Page 6]
Internet-Draft      EPP Pre-Registration Verification      November 2023

6.  EPP Protocol Extension

6.1.  Extended "create" Command for Pre-Registration and Quality
      Verification

   This section outlines the extension of the existing "create" EPP
   command to accommodate the pre-registration data submission and
   quality verification process.  The extended "create" command enables
   registrars to provide additional information related to the intended
   use of the domain name, facilitating quality assurance within the
   top-level domain (TLD).

6.1.1.  Command Name

   Command Name: "create" (Extended)

6.1.2.  Command Purpose

   The extended "create" command serves the following purposes: - To
   create a new domain registration within the TLD. - To allow
   registrars to submit pre-registration data for quality verification.
   - To enhance the quality assurance process by providing registrars
   the opportunity to convey relevant information about the domain's
   intended use.

6.1.3.  XML Element Extension

   To enable registrars to submit pre-registration data, the "create"
   command is extended to include an optional XML element, <pre-
   registration-data>.  This XML element is included within the "create"
   command's payload and encapsulates the pre-registration information
   provided by the registrar.

   *_XML Element:_*

   *  <pre-registration-data> (Optional)

6.1.4.  Usage

   Registrars initiate the extended "create" command in the following
   manner:

   *  The registrar includes the <pre-registration-data> XML element
      within the "create" command when submitting a domain registration
      request.

Latour, et al.             Expires 18 May 2024                  [Page 7]
Internet-Draft      EPP Pre-Registration Verification      November 2023

   *  The <pre-registration-data> element allows registrars to provide
      information related to the intended use of the domain, additional
      contact details, or any other relevant data.

   Example "create" Command with Pre-Registration Data:

   <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
        <command>
          <create>
            <!-- Domain creation data -->
            <domain:create>
              <!-- Domain details -->
            </domain:create>
            <!-- Pre-Registration Data -->
            <pre-registration-data>
              <!-- Pre-registration information -->
            </pre-registration-data>
          </create>
        </command>
      </epp>

   The inclusion of the <pre-registration-data> element within the
   "create" command allows registries to participate in the quality
   assurance process and ensures that additional data relevant to the
   domain's use is considered prior its potentially abusive
   registration.

   Extended "create" Command: The existing "create" command will be
   extended to include an optional XML element for registrars to submit
   pre-registration data.  This will enable registrars to provide
   additional information related to the intended use of the domain
   name.

6.2.  Introduction of New Verify EPP Commands

   New "verify" Command: A new EPP command, "verify" will be introduced
   to trigger the quality verification process on the submitted pre-
   registration data.  Registrars can use this command after the initial
   "create" request.  It's important to note that the time to respond to
   the verify command is important to take in account, should be in the
   order of seconds and not minutes.

Latour, et al.             Expires 18 May 2024                  [Page 8]
Internet-Draft      EPP Pre-Registration Verification      November 2023

6.3.  Command Flow Overview

   Command Flow: The process begins with a registrar initiating a
   "create" command with additional pre-registration data.  The
   registry, upon receiving the request, stores the data for further
   analysis.  Once the data is collected, the registrar can initiate the
   "verify" command to trigger the quality verification process, which
   results in the assignment of a quality score.  By mapping the EPP
   verify commands to the new registration process, it demonstrate how
   the new extension fits into the existing EPP framework and how it can
   facilitate the pre-registration data submission and quality
   verification.

7.  Pre-Registration and Verification Command Flow

7.1.  Pre-Registration Data Submission Flow

   The command flow within the EPP protocol extension for pre-
   registration and quality verification is a series of interactions
   between the registrar and the registry.  This section outlines the
   steps involved in submitting pre-registration data and initiating the
   quality verification process:

   *_Step 1: Registrar Initiates "create" Command_*

   The process begins when a registrar initiates a modified "create"
   command, extending the EPP protocol.  This command is used to request
   the creation of a new domain registration.

   *_Step 2: Registrar Includes Pre-Registration Data_*

   Within the "create" command, the registrar includes the <pre-
   registration-data> XML element.  This element encapsulates the pre-
   registration information, such as the intended use of the domain and
   any other relevant data.

   *_Step 3: Registry Receives and Stores Pre-Registration Data_*

   The registry, upon receiving the "create" command, stores the pre-
   registration data associated with the domain name in question.  This
   data is queued for subsequent quality verification.

7.2.  Quality Verification Flow

   After pre-registration data is successfully submitted through the
   "create" command, the quality verification process can be initiated
   by the registrar.  Here's how the flow continues:

Latour, et al.             Expires 18 May 2024                  [Page 9]
Internet-Draft      EPP Pre-Registration Verification      November 2023

   *_Step 4: Registrar Initiates "verify" Command_*

   After the pre-registration data has been stored, the registrar
   initiates the "verify" command, a new EPP command introduced by this
   extension.

   *_Step 5: Registry Triggers Quality Verification_*

   Upon receiving the "verify" command, the registry's system is
   triggered to initiate the quality verification process.  This process
   involves AI/ML analysis of the pre-registration data.

   *_Step 6: AI/ML Analysis and Quality Score Calculation_*

   The registry's AI/ML algorithms analyze the pre-registration data to
   assess its quality.  This analysis considers factors such as the
   nature of the registration, the intended use of the domain, and other
   relevant data.  Based on the analysis, the system calculates a
   registrant quality score.

   *_Step 7: Registry Provides Quality Score_*

   The registry sends the registrant quality score as part of the
   "verify" command response to the registrar.  The score indicates the
   perceived quality of the registration, with values ranging from 0 for
   non-abusive registrations to 100 for potentially abusive ones.

   *_Step 8: Registrar Takes Action Based on Quality Score_*

   Depending on the quality score received, the registrar can make
   informed decisions regarding the acceptance, rejection, or further
   review of the domain registration request.

8.  Pre-Registration Quality Score *_Guidance_*

   This section provides a range of registrant quality scores with
   corresponding actionable actions for the proposed quality
   verification process, where 0 indicates a good registration and 100
   signifies an absolutely malicious registration:

8.1.  Score 0 - 20 (Non-Abusive):

8.1.1.  Actionable Actions:

   *  The registration appears to be non-abusive and legitimate.

   *  The address and information provided by the registrant match and
      seem trustworthy.

Latour, et al.             Expires 18 May 2024                 [Page 10]
Internet-Draft      EPP Pre-Registration Verification      November 2023

   *  No immediate action required.

8.2.  Score 21 - 40 (Low Suspicion):

8.2.1.  Actionable Actions:

   *  The registration raises minimal suspicion.

   *  While the information appears consistent, there might be subtle
      irregularities.

   *  Regular monitoring and further review may be necessary.

   *  Regular monitoring and further review may be necessary.

8.3.  Score 41 - 60 (Moderate Suspicion):

8.4.  Actionable Actions:

   *  The registration raises moderate suspicion.

   *  Some elements in the registration data seem incongruent or
      questionable.

   *  Investigate further and consider additional verification steps.

   *  Suspend the registration at the Registry? (after Registrar
      registration)

8.5.  Score 61 - 80 (High Suspicion):

8.5.1.  Actionable Actions:

   *  The registration exhibits a high level of suspicion.

   *  Several aspects of the registration data appear inconsistent or
      potentially problematic.

   *  Immediate investigation and verification are necessary.

   *  Suspend the registration at the Registar

8.6.  Score 81 - 99 (Very High Suspicion):

8.6.1.  Actionable Actions:

   *  The registration is highly suspicious and raises significant
      concerns.

Latour, et al.             Expires 18 May 2024                 [Page 11]
Internet-Draft      EPP Pre-Registration Verification      November 2023

   *  Multiple elements in the registration data are irregular or seem
      malicious.

   *  Implement rigorous verification and consider delaying or rejecting
      the registration.

8.7.  Score 100 (Absolutely Malicious):

8.7.1.  Actionable Actions:

   *  The registration is deemed absolutely malicious and poses a severe
      threat.

   *  Clear evidence of fraudulent activity or malicious intent is
      present.

   *  Reject the registration and take appropriate measures to prevent
      abuse.

   These quality score ranges and associated actions provide guidance
   for registrars and registries in evaluating the legitimacy of domain
   registrations.  The specific actions to be taken can vary depending
   on the policies and procedures of the TLD registry and the severity
   of the suspicions raised by the quality score.

8.8.  Error Handling

   TBD

8.9.  Registration Timing Considerations

   This process has to be quick, if too slow a timer must be defined to
   mark the registration verification as incomplete, need a specific
   workflow

9.  Security Considerations

   TODO Security

10.  IANA Considerations

   This document has no IANA actions.

11.  Normative References

Latour, et al.             Expires 18 May 2024                 [Page 12]
Internet-Draft      EPP Pre-Registration Verification      November 2023

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

Acknowledgments

   TODO acknowledge.

Authors' Addresses

   Jacques Latour
   CIRA
   Email: jacques.latour@cira.ca

   Don Slaunwhite
   CIRA
   Email: don.slaunwhite@cira.ca

   Tim Johnson
   InternetNZ
   Email: timj@internetnz.net.nz

Latour, et al.             Expires 18 May 2024                 [Page 13]