Re: [regext] EPP Transport Service Discovery

The. Certificate problem can be dealt with as elsewhere: switch to DANE and stop accepting CA certs. 

                -Bill

> On Mar 20, 2024, at 5:33 AM, Francisco Obispo <fobispo@tucows.com> wrote:
> 
> This is a neat idea,
> 
> Is there a reasoning or use case for such need?
> 
> One of the challenges that I see, is that knowing the server address is one thing, but generally clients (registrars) keep the connections open for a long period of time, so the need to reduce the connection speed may not be a big advantage in practice. (if this is the argument)
> 
> Additionally to connect to an EPP server you will need some sort of client credentials and a form of client certificate pinning which is usually negotiated and exchanged out-of-band.
> 
> I am curious to understand the reasoning behind this need
> 
> Best regards,
> 
> Francisco
> 
>> On 19 Mar 2024, at 19:11, Hollenbeck, Scott wrote:
>> 
>> As noted during this morning’s regext session, we need to consider how a client can discover the transport services provided by an EPP server. Opportunistic probing is one method, another is server capability publication using something like an SVCB record that’s published in a DNS zone maintained by the EPP server operator. Perhaps something like this:
>> 
>> epp.example.net.  7200  IN SVCB 3 epp.example.net. (
>> 
>>        alpn="bar" port="700" transport="tcp")
>> 
>> There is no “transport” SvcParamKey currently registered with IANA, but that’s easy to do. I think there’s a draft here that needs to be written.
>> 
>> Scott
> 
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext