Re: [regext] I-D draft-latour-pre-registration

"Gould, James" <jgould@verisign.com> Fri, 17 November 2023 13:30 UTC

Return-Path: <jgould@verisign.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E8AC15171B for <regext@ietfa.amsl.com>; Fri, 17 Nov 2023 05:30:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.006
X-Spam-Level:
X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHopXqzLSbFo for <regext@ietfa.amsl.com>; Fri, 17 Nov 2023 05:30:07 -0800 (PST)
Received: from mail6.verisign.com (mail6.verisign.com [69.58.187.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CB67C14CE36 for <regext@ietf.org>; Fri, 17 Nov 2023 05:30:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=50994; q=dns/txt; s=VRSN; t=1700227808; h=from:to:cc:date:message-id:mime-version:subject; bh=/SD4qyxpwTbOOzIYBm3OcgeBktcIiyst3GpECKoc7C4=; b=V8wIJeZWsqV6ak1je9yoypeDfHcU3hhEfqyaMxTF4WczOVU8B8g+kPLb 7sIaglemXsJzPYpD9yRsDO+bI7SSij1a9iYM1/0B6kkGPPjI+mfDjmky7 vsO4AR9jKAxbqcnWGUETNvzoOevHZ3uvZdJQZvm58YwBu9Ok/OTyrFX/p 4pWyHZ7vK10O3ISK8TSDkOgfKB17lXmqCf8wWK6L6ASJn69hJZs9VAgY6 JhEUJh1nzwvD4htqTy9ZT0YkaCVe3oY2n+AENt2We1V2yVp74GVH+Y8me jA+qTipkcpi1DrmuwqyYKuwkNXU8VQBQ+exs512hPp8HBekWOCQjWPCEE w==;
IronPort-Data: A9a23:hjoW4Km372CVsQbSEd61hh7o5gzEJkRdPkR7XQ2eYbSJt16W5oE+e lBvADTXbaqKYmPrO4chWDmFhRxUvsOHyNIwTARlrChjH3kTo8aZDt/FchmpYCmfJJGdRxtss ZRPN9ScJ5s+HnaB+k6nbObv9iQh2/+CHbGkV+Os1kydJONBYH5JZUVLx7dg3OaE+OSEPj5hm e8eguWFMgSvhWJ/aj5Ouv2O8U8w7f/+4D9JslJgPa5F7AHTyyVMXMMUKJ/qIiqjSOG4PAIYq 8Xrl+jlozyDr3/BLvv/z94Xp2VTGua60TCm0yYQAe746vR7jnRa+r4hM/YBYltghTyMntRgo P1ArpXYpT0BZ8Ugo8xDFUEEe81CFfceouSeeCHg6Zb7I3DuKBMA/d0/VCnaAqVFoo6bMUkWn dQEJTYEaAy0hu7e6NpXncE126zPhOGyVG8ukikIIQPxVJ7KcriaK0n+3uK06R9r7ix4Na2HO 5dGM2oHgCPoOHWjMn9PYH43tLnw2imnK1W0onrNzUY8yzC7IACcTNEBmTcaEzCHbZw9o6qWm o7J137oAk4/GtC78iOc/0/r3tWWoDyiZ51HQdVU9tYy6LGS7kYpLkQpc3aL+aP/lEW5QcoZI kBS5DA1q+4580nDotvVBkX++SHf+EdBAJwMQoXW6ynUokbQywSWAXUAQhZfZcYnr845Q3oh0 Vrhc9bBX2E16eHEGC/1GrG8sxavNQ5IAm07QHEoElcU4ITNrL0/kUeaJjpkOOvv5jHvIhnyw DeOryUk0ulLgskH3qm37BbMhDeEqp3AVAVz5wjLUCSi9AwRTKysbJW15EOdyf9cK5uDGwXZt 3keko6V5cgCCJiXn2qMTfkDWraz6J6tKjDTjE5zN5gs6zrr/GSsFah85zc4H0NgL8AbeT71b WfYuBlYopRaVFO2bKp1S4O3F8kwy6X8E8ajUP3IKNxcCqWdbyeN5ic3ekidzzi31VMyi+c6O Izee8HqB2wcUOJ51iGwAewa1NfH2xwD+I8afrijpzzP7FZUTCf9pWstWLdWUt0E0Q==
IronPort-HdrOrdr: A9a23:dYZeJKEFCfn5FvbfpLqExseALOsnbusQ8zAXPhhKOH5omszxra yTdYcgpHrJYVcqKQodcL+7WJVoLUm3yXcX2/hqAV7BZniEhILAFugLhrcKqAeOJ8SKzI9gPN BbHZSWZuecMbEwt7ef3ODxKadG/DGKnZrY/Ns3hR1WPGdXgo9bnn9ENjo=
X-Talos-CUID: 9a23:j9EM6220yUWPKm7KjHuTLrxfANElLVjzwFPrOla1NCExcuSoVgav5/Yx
X-Talos-MUID: 9a23:aLsFIgX6Bv5O3B7q/CHJmT1Eaehq2oHwJB9RgJZblcW4OTMlbg==
X-IronPort-AV: E=Sophos;i="6.04,206,1695700800"; d="png'150?scan'150,208,217,150";a="25214995"
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.34; Fri, 17 Nov 2023 08:30:05 -0500
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([10.173.153.48]) by BRN1WNEX01.vcorp.ad.vrsn.com ([10.173.153.48]) with mapi id 15.01.2507.034; Fri, 17 Nov 2023 08:30:05 -0500
From: "Gould, James" <jgould@verisign.com>
To: "jkolker=40godaddy.com@dmarc.ietf.org" <jkolker=40godaddy.com@dmarc.ietf.org>, "Jacques.Latour=40cira.ca@dmarc.ietf.org" <Jacques.Latour=40cira.ca@dmarc.ietf.org>, "regext@ietf.org" <regext@ietf.org>
CC: "Don.Slaunwhite@cira.ca" <Don.Slaunwhite@cira.ca>, "timj@internetnz.net.nz" <timj@internetnz.net.nz>
Thread-Topic: [EXTERNAL] Re: [regext] I-D draft-latour-pre-registration
Thread-Index: AQHaGVotI+u3YrKIQ4WhFt99Gj3vng==
Date: Fri, 17 Nov 2023 13:30:05 +0000
Message-ID: <AD61A74F-437A-4C86-8857-627171597D28@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.78.23100802
msip_labels: MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_ActionId=b5d9efc7-f249-437f-9abe-c70232831771; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_ContentBits=0; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_Enabled=true; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_Method=Standard; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_Name=Confidential; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_SetDate=2023-11-15T15:47:46Z; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_SiteId=f349b30c-7550-4f17-88da-269417631f54;
x-originating-ip: [10.170.148.18]
Content-Type: multipart/related; boundary="_004_AD61A74F437A4C868857627171597D28verisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/G_JdiPbYOMjMvY5DDrRegCtMpBo>
Subject: Re: [regext] I-D draft-latour-pre-registration
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Nov 2023 13:30:12 -0000

Jacques,

Very interesting brain teaser.  I concur with Jody that for performing the verification in the registration, the pending create model via the 1001 response to the domain create can be used to perform the server-side verification if it cannot be done immediately along with the pending action poll message.  The verification detail could be included as an extension to the pending action poll message if a simple boolean is not enough.

For the pre-verification, I see multiple options:


  1.  Create an extension of the domain object mapping, like what you have defined in draft-latour-pre-registration.  You would need to create new EPP verbs.  As stated by Jody, use an extension of the check command, either an extension of the availability check, as demonstrated by the Registry Fee Extension in RFC 8748, or the definition of a new verification check verb, as demonstrated by the claims check in the Launch Phase Extension in RFC 8334.  I get the feeling that the verification is more unique and better suited for a separate verb.  Anything beyond creating a new check verb will run into complexities.
  2.  Create a separate verification object mapping with the full suite of commands (check to do a quick verification, create to start a longer verification, update to change a pending verification, info to get the state of the verification and to receive a verification token, poll message of info response sent by the server).  The China Name Verification Mapping in draft-ietf-regext-nv-mapping is an example of defining a verification object mapping.  In the case of the China Name Verification Mapping, a successful verification resulted in the generation of the digitally signed verification code that complies with the Verification Code Extension in draft-ietf-regext-verificationcode.  The concept of the use a digitally signed verification code works well if a 3rd party is performing the verification function, which doesn’t sound like the case that you’re looking to do.  If the same party is performing the verification that later receives proof via a generated token, you may not have the need for digital signing.  You could leverage the Allocation Token Extension in RFC 8495 to contain the verification token that could authorize the registration.

Based on the experience that I’ve had with verification; my recommendation is to go down option #2 so that you can specifically define the interface that is needed for pre-verification without the complexity of having to define new verbs.  There are many options related to providing the results of the verification in the registration, if that is what is needed, such as the use of a token that is passed in the Allocation Token Extension, or a digitally signed typed code that is passed in the Verification Code Extension, or caching the verification in the registry based on the domain name without the need to pass anything, or creating a custom extension of the Domain Object Mapping to pass the generated verification information.

Thank you for sharing,

--

JG

[cid87442*image001.png@01D960C5.C631DA40]

James Gould
Fellow Engineer
jgould@Verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: regext <regext-bounces@ietf.org> on behalf of Jody Kolker <jkolker=40godaddy.com@dmarc.ietf.org>
Date: Thursday, November 16, 2023 at 3:24 PM
To: Jacques Latour <Jacques.Latour=40cira.ca@dmarc.ietf.org>, "regext@ietf.org" <regext@ietf.org>
Cc: Don Slaunwhite <Don.Slaunwhite@cira.ca>, "timj@internetnz.net.nz" <timj@internetnz.net.nz>
Subject: [EXTERNAL] Re: [regext] I-D draft-latour-pre-registration


Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi Jacques,

A couple of observations:


  1.  Would it be possible to allow the registry to determine if the verification can be done instantly or needs to be delayed.  If it is instantly, return a 1000 with the results, if it can’t return 1001.  If the verification can be done instantly a verification command is not needed.
  2.  If 1001 is returned from the command,  I would imagine the registry would through the information on a queue to be reviewed, and once reviewed, the registry could send a poll back to the registrar, thereby eliminating the need for a verification command and allowing the registry to perform deeper analysis if needed.  I can imagine that this process will not be in the purchase path for a domain, but will happen after the domain is purchased, but not registered.  Waiting for a poll message might be perforable.
  3.  From a purely semantic point of view, should this extension be sent with the check command instead of the create command?  The object is not created but is being verified, more of a check (even though the objects may be temporarily created).


Thanks,
Jody Kolker
319-329-9805  (mobile)

Please contact my direct supervisor Scott Courtney (scourtney@godaddy.com<mailto:scourtney@godaddy.com>) with any feedback.

This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments.

From: regext <regext-bounces@ietf.org> On Behalf Of Jacques Latour
Sent: Wednesday, November 15, 2023 9:57 AM
To: regext@ietf.org
Cc: Don Slaunwhite <Don.Slaunwhite@cira.ca>; timj@internetnz.net.nz
Subject: [regext] I-D draft-latour-pre-registration


Some people who received this message don't often get email from jacques.latour=40cira.ca@dmarc.ietf.org<mailto:jacques.latour=40cira.ca@dmarc.ietf.org>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>

Caution: This email is from an external sender. Please do not click links or open attachments unless you recognize the sender and know the content is safe. Forward suspicious emails to isitbad@.


Hi all,

At the ICANN78 meeting and other venues, there were quite a lot of discussion on AI/ML abuse detection related discussions and presentations.

  *   Example: https://static.sched.com/hosted_files/icann78/de/4%20%2020231023-TechDay-AI%20at%20EURid.pdf<https://secure-web.cisco.com/12rIPwEOtGUvSjI4Bm4omHESSzfohjoDZXoWK_SJ0JceMVnIHvXUA4uOxNLHClainv3lR8Iu1lg3R9IjJbCDqqgbkk6bxoJuW-WEYEqrJLRklkZGR-Ct-hZXS6ktKA09pg7yVtmDKvfa0SobiOeP_I6Mz8uun1YtEPX91jX7BRI-d0kcwx2YUNxg58ZYUPNa3yMlk00rur63csO_DlZTsnjDhtC_XYX-9orqVi-X1xfM2Aha26SYTQDmXSc-n98QTh_FVWltL3NxErFuGP69L9WMfIV925CW0qAJA-rEPRw4/https%3A%2F%2Fstatic.sched.com%2Fhosted_files%2Ficann78%2Fde%2F4%2520%252020231023-TechDay-AI%2520at%2520EURid.pdf>

But this is after the fact, after a registration is completed, so we thought of a new extension to allow the registrar to ask the registry that have this real time capabilities to analyse the pre-registration information and return a quality score to better inform the process.

draft-latour-pre-registration-00 - EPP Pre-Registration Verification (ietf.org)<https://secure-web.cisco.com/1_jZTM-EIfQE0A9btVogGNAmEWA6-k_ocgUj27qEQJSEFT4g3e9V1khb3itUP9_Atcoc9bAt0jXyiErP-KM2wxhMIBuer4P76mU8LG45fUrSoG45Yt2A1wgu3IL2JOXVH0zi5qq86QWull-Dz6KljwA70I4jY0g2andFWMRpYzp3Z9VPVlJxKI5A6T77jLl9sTOOIrK-2uEj9wcR6x1j27jExaaFAS0Ylty2r63_dVBZf145elouIlY84GdmFWvijV2dmcpOWawZZiTrx5jQG3OvlXmF0bYKfEgixewavw08/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-latour-pre-registration%2F>

Have a read,

Jack


CLASSIFICATION:CONFIDENTIAL