[regext] EPP Extension Object Search

[Tobias Sattler]

Dear Working Group,

Jody and I wrote a draft on EPP Extension called Object Search.

We want to spin this idea with this group because using EPP for searching is 
more secure than RDAP by reducing a threat vector.

https://github.com/seitsu/epp-object-search/blob/main/draft-sattler-epp-object-search.txt
 


Please note that this is an early draft that is not submitted yet. Therefore, 
the approach used in this document is only to illustrate the idea, not 
necessarily the final approach.

We are looking forward to hearing your feedback.

Thanks,
Tobias___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] EPP Extension Object Search

[Thomas Corte (TANGO support)]

Hello,

On 12/14/21 15:29, Tobias Sattler wrote:


Dear Working Group,

Jody and I wrote a draft on EPP Extension called Object Search.

We want to spin this idea with this group because using EPP for searching 
is more secure than RDAP by reducing a threat vector.


https://github.com/seitsu/epp-object-search/blob/main/draft-sattler-epp-object-search.txt 



Please note that this is an early draft that is not submitted yet. 
Therefore, the approach used in this document is only to illustrate the 
idea, not necessarily the final approach.


We are looking forward to hearing your feedback.


As a (registrar) EPP client developer, I'd surely actually welcome a way 
to obtain ad-hoc lists of sponsored objects via EPP (rather than having 
to rely on out-of-band reports, which aren't really standardized yet, see 
below).



However, as a (registry) EPP server developer, I'm wary of the extra 
stress that could be caused by excessive list queries (with search 
filters) hitting the main SRS database, especially if registrars took the 
availability of this feature as an incentive to neglect their local 
inventory management.


This is one of the reasons why our own TANGO registry system is using a 
dedicated reporting server that offers daily inventory reports, 
pre-generated from a local, partial copy of the registry's data.



The registration reporting draft at

https://datatracker.ietf.org/doc/draft-ietf-regext-simple-registration-reporting/

seems to be aiming at standardizing such registry reports, which at this 
point seems to be the preferable option to get inventory information IMHO 
- registrars could use them to easily get full inventory data, allowing 
them to filter them offline in any way they see fit (compared to the 
simple filtering options the object search branch offers right now). 
Also, the standardized reports are supposed to also include data about 
transactions, RGP, reserved names, premium names etc.; the EPP object 
search would really only offer a small subset of this data.


By the way, the text and examples don't seem to be aligned with the XSD 
in the draft; for example, "type" and "filter" are defined as XML 
elements, while they occur as XML attributes in the examples.


Best regards,

Thomas

--
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbHThomas Corte
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund  E-Mail: thomas.co...@knipp.de
Germany

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] EPP Extension Object Search

[Patrick Mevzek]

On Tue, Dec 14, 2021, at 09:29, Tobias Sattler wrote:
> We want to spin this idea with this group because using EPP for 
> searching is more secure than RDAP by reducing a threat vector.

Which threat vector? Or can you explain what is not secure in RDAP?
Because it uses HTTPS so it can be "secured" by any and all well-known 
mechanisms,
from shared secret, to full Oauth/WebAuthn things.

Also the exact same EPP security mechanisms (as laid out by RFC5734), namely
1) IP access lists 2) clients X509 certificates 3) login+password, can be done 
exactly
as is with RDAP, if so wished.

EPP is Extensible *Provisioning* Protocol (yes, I know not fully true already).
I am into the personal position that a lot of stuff added lately/being added to 
EPP would in fact have been better through RDAP, because it also for some opens 
the use by other
entities than registrars.

I think the authentication/authorization stuff is orthogonal to the features 
provided
by the protocol.

-- 
  Patrick Mevzek
  p...@dotandco.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] WG LAST CALL: draft-ietf-regext-epp-eai-04

[Taras Heichenko]

The comment is in body.

> On 13 Dec 2021, at 15:15, Hollenbeck, Scott 
>  wrote:
> 
>> -Original Message-
>> From: Gould, James 
>> Sent: Thursday, December 9, 2021 11:59 AM
>> To: Hollenbeck, Scott ;
>> ietf=40antoin...@dmarc.ietf.org ; regext@ietf.org
>> Subject: [EXTERNAL] Re: Re: [regext] WG LAST CALL: draft-ietf-regext-epp-
>> eai-04
>> 
>> 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.
>> 
>> Scott,
>> 
>> Thanks for the review and feedback.  I provide responses to your feedback
>> embedded below.
>> 
>> --
>> 
>> JG
>> 
>> 
>> 
>> James Gould
>> Fellow Engineer
>> jgo...@verisign.com > B4BA42740803/jgo...@verisign.com>
>> 
>> 703-948-3271
>> 12061 Bluemont Way
>> Reston, VA 20190
>> 
>> Verisign.com > web.cisco.com/1bUEhaRz5CoSQPd4colm8eTGE5D6zPQvtrYPAzQf9pUSXnqD
>> Nq7mmnlZ8At92joPzY5DkJdQiiPe1mlyvgzDAdDz_shcqHzSugkfXA2qX9z7aQp0
>> 6ld-
>> LnwMzxo2VGkwqFH5gLrI7qSYQlgj4Unll4AIUd6ALSZ38i2kjYqgA0AnBBjaJEVg7
>> yUIN-
>> P8bpFGxQgN__tWour_sxUBBx2vUcVpmrR7SUG6UsUo5U3gb_YbWCYcRn8b
>> 4Rl06BQIL8B8k/http%3A%2F%2Fverisigninc.com%2F>
>> 
>> On 12/6/21, 9:18 AM, "regext on behalf of Hollenbeck, Scott" > boun...@ietf.org on behalf of shollenbeck=40verisign@dmarc.ietf.org>
>> wrote:
>> 
>> 
>>A few questions/comments:
>> 
>>Section 6: We need to provide the rationale for that SHOULD (Registries
>> SHOULD validate the domain names in the provided email addresses). What
>> does "validate" mean? For syntax? For reachability?
>> 
>> JG - This is associated with validating the syntax.  The goal is to ensure 
>> that
>> the domain name, whether an ASCII or IDN domain name is a syntactic valid
>> domain name the may be reachable.  Would it help to modify this to read
>> "Registries SHOULD validate the syntax of the domain names in the provided
>> email addresses so they may be reachable."?
> 
> [SAH] Syntax validity is no guarantee of reachability. The only way to 
> confirm 
> that an email address "works" is to send email to that address and confirm 
> that it's delivered. I don't think we want to suggest that registries should 
> start sending out email delivery tests, so maybe something like this instead:
> 
> " Registries SHOULD ensure that the provided email addresses are 
> syntactically 
> valid to reduce the risk of future usability errors."

The check of existing of the domain (MX or at least A/ record) from the
email address may be added. I am not sure that it should be there but it also
raises the probability that the email address is valid.

> 
>>Section 7: What's significant about "eai-0.3"? The "0.3" part doesn't 
>> track to
>> the current version of the draft; perhaps "1.0" would be better now. See 
>> also
>> Section 5.2.
>> 
>> JG - Yes, the namespace will be changed to "eai-1.0" once it passes WGLC
>> similar to what has happened in past EPP extensions with pointed
>> namespaces.
> 
> [SAH] OK.
> 
>>Section 8: It might be helpful to add more text to explain why 
>> "Registries
>> MAY apply extra limitation to the email address syntax". Why might they
>> want to do that? It seems a little unusual to say that they MAY do 
>> something,
>> but in the next sentence say, "These limitations are out of scope of this
>> document".
>> 
>> JG - Agreed, this does not look to add value.  Do you believe the
>> Implementation Considerations section should be removed, since the
>> contents really don't provide any material considerations?
> 
> [SAH] Yes, that's probably a good idea.
> 
> Scott
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

--
Taras Heichenko
ta...@academ.kiev.ua





___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext