Subject: Re: [regext] Fwd: New Version Notification for draft-loffredo-regext-epp-over-http-00.txt

From: "Gould, James" <[email-masked]>
Date: Wed, 2 Mar 2022 13:01:04 +0000

Mario,

Thank you for sharing the draft.  We implemented EPP/HTTPS in parallel with EPP/TLS a while back for many years.  In the end, there were very few registrars that chose to use EPP/HTTPS, so it was shutdown.  I’m not sure at this point whether there is hunger from the registrars to implement EPP/HTTPS.

In reviewing the draft, one difference with our EPP/HTTPS implementation is that establishing the HTTPS session was separate from establishing the EPP session, like what is done with TLS.  The HTTPS session was established with returning the greeting, and the only EPP command that impacted the HTTPS session was the logout command by dropping the HTTPS session, like the logout command dropping the TLS connection on the server-side.  By not mixing the EPP commands with the underlying transport, it was possible to configure the transport (TLS or HTTPS) on the client-side, as was done in our EPP SDK.  My recommendation is to ensure to keep the transport purely a transport and not have the login command intermingled with the HTTPS session.  One other difference was the use of the media type “text/xml” instead of defining a new one with “application/epp+xml”.  The EPP packet length was set with the “Content-Length” header along with relying on the HTTP keep-alive, which is consistent.

--

JG

James Gould
Fellow Engineer
[email-masked]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>

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

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

From: regext <[email-masked]> on behalf of Mario Loffredo <[email-masked]>
Date: Wednesday, March 2, 2022 at 6:47 AM
To: "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] [regext] Fwd: New Version Notification for draft-loffredo-regext-epp-over-http-00.txt

Hi folks,

Just posted a draft about EPP over HTTP.  It aims to define rules for the EPP implementations leveraging HTTP due to its simplicity and ease of use.

The proposal preserves EPP commands semantics as HTTP is used merely for transportation.

The appendix includes possible strategies about how to implement load balancing in this context.

Even if EPP is largely implemented over TCP, some HTTP based implementations exist and a standardization would be advisable.

Feedback is welcome and appreciated.

Best,

Mario

-------- Messaggio Inoltrato --------
Oggetto:

New Version Notification for draft-loffredo-regext-epp-over-http-00.txt

Data:

Wed, 02 Mar 2022 03:16:34 -0800

Mittente:

[email-masked]<mailto:[email-masked]>

A:

Jan Romanowski <[email-masked]><mailto:[email-masked]>, Lorenzo Luconi Trombacchi <[email-masked]><mailto:[email-masked]>, Lorenzo Trombacchi <[email-masked]><mailto:[email-masked]>, Marcin Machnio <[email-masked]><mailto:[email-masked]>, Mario Loffredo <[email-masked]><mailto:[email-masked]>, Maurizio Martinelli <[email-masked]><mailto:[email-masked]>

A new version of I-D, draft-loffredo-regext-epp-over-http-00.txt
has been successfully submitted by Mario Loffredo and posted to the
IETF repository.

Name: draft-loffredo-regext-epp-over-http
Revision: 00
Title: Extensible Provisioning Protocol (EPP) Transport over HTTP
Document date: 2022-03-02
Group: Individual Submission
Pages: 15
URL: https://www.ietf.org/archive/id/draft-loffredo-regext-epp-over-http-00.txt<https://secure-web.cisco.com/1f30dq890q6OrF7oLq92m2FwCsaQYGofA9g5UVFZlHkmN0w_yAnbxq9DW0cng9yq1vWPgqDHusaG7I_pd7Fj4HY4k3E12N2lZ1KQR3XYcBxZ4Fuq9uL9cyPCZGPD3SOU9UVMWBvgLccCqeZcoPppgb79gEzOCSU6xUIxnQSxEIOdQ2IKNsK1iLRDUhVmqdA8sjpP4A2mavGo2L5DF-Rx07Nx3vWgTgiFN-5fKLapEn2ndXKhlxVnDE0uw7Et2CWck/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-loffredo-regext-epp-over-http-00.txt>
Status: https://datatracker.ietf.org/doc/draft-loffredo-regext-epp-over-http/<https://secure-web.cisco.com/1e-EzKBW4F-ke3YB-EbSecmjRZQjNyGt_AMB9DoqHhXoy2emw5WScEOrERmcHKLufTmxRFNsSsmi2oDZHMu2PosarH3O8FtwH1h7eWpFvAWPvg_TxYpepR-EMI0eWP6gZukKJFDy0UrW-9LO27dgrGaoRyo53ZYM_1bvPZL3semd5_mD2xUD09Tx-pBTyR3lqjDXTV2_g_62iZ27ixUHPJNt6mDbIwagHhxDOeQByS1qTEuJMznqU19N9rhdi_JV4/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-loffredo-regext-epp-over-http%2F>
Htmlized: https://datatracker.ietf.org/doc/html/draft-loffredo-regext-epp-over-http<https://secure-web.cisco.com/1wiuZNeJDCZOU0TRLJxGBsMS3mMMkykHo-jJZpWgFbcjOdAwcTy9S0z2HvH9BdlOc063zPjm2eB0NDa3UBBVvNeZ3TdDbuj5ewbxTjc-VWO2ctIq10oOq_toZDXhDx-I469jfy6dBn3OxeBJfSQctig1xhdc5gOJlsHzlfbxkntqMg14jsEigdNdcXuV5YqBxO4d8vMNPugQX3z3bk-gE4ETukCyRhHsOIlM6DRumLe5OUtqKX74_yIT5Oc-ZoD0C/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-loffredo-regext-epp-over-http>

Abstract:
This document describes how the Extensible Provisioning Protocol
(EPP) is mapped over the Hypertext Transfer Protocol (HTTP). This
mapping requires the use of the Transport Layer Security (TLS)
protocol to protect information exchanged between an EPP client and
an EPP server.

The IETF Secretariat

---

From: Gavin Brown <[email-masked]>
Date: Wed, 2 Mar 2022 14:29:59 +0000

Hi Jim and Mario,

> On 2 Mar 2022, at 13:01, Gould, James <[email-masked]> wrote:
> 
> Mario,
>  

At least one registrar (DNSimple) had a go at writing an EPP over HTTPS spec a few years ago, regrettably it didn't get very far (for which I am partly to blame):

https://github.com/aeden/epp-over-http

I think now is a good time to reassess the appetite for EPP over HTTPS. As we all move to the cloud, where almost everything uses HTTP as a substrate, it becomes harder to deploy protocols that aren't based on HTTP in a cloud-native way, both on the client side and the server side.

From the security point of view, while EPP has a relatively small attack surface, if you're a registry, you're somewhat limited in terms of the third-party security services you can deploy to protect it. The same is true of whois, but at least we know that whois will one day be replaced by RDAP, which is HTTP based. I look forward to one day putting my entire infrastructure behind $YOUR_CLOUD_BASED_REVERSE_PROXY_OF_CHOICE - which necessitates retiring (or at least deprecating) ports 43 and 700.

G.

--
Gavin Brown
Head of Registry Services
CentralNic Group plc (LSE:CNIC)
https://centralnicregistry.com

Cal: http://cnic.link/gbcalendar

CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 6BR.

https://www.centralnic.com

---

From: Mario Loffredo <[email-masked]>
Date: Wed, 2 Mar 2022 17:56:13 +0100

Hi James,

thanks a lot for your feedback.

My comments are below.

Il 02/03/2022 14:01, Gould, James ha scritto:
>
> Mario,
>
> Thank you for sharing the draft.  We implemented EPP/HTTPS in parallel 
> with EPP/TLS a while back for many years.  In the end, there were very 
> few registrars that chose to use EPP/HTTPS, so it was shutdown.  I’m 
> not sure at this point whether there is hunger from the registrars to 
> implement EPP/HTTPS.
>
[ML] Maybe one reason against the implementation of EPP over HTTP thus 
far has been the lack of a specification about it :-)

I believe that, especially for those registries accostumed to develop 
their systems in-house, EPP over HTTP can be more straightforward than 
EPP over TCP.

Implementers are normally more knowledgeable about REST programming than 
TCP sockets and web services can benefit from a lot of open-source 
software managing automatically some features and providing support for 
many others.

> In reviewing the draft, one difference with our EPP/HTTPS 
> implementation is that establishing the HTTPS session was separate 
> from establishing the EPP session, like what is done with TLS.  The 
> HTTPS session was established with returning the greeting, and the 
> only EPP command that impacted the HTTPS session was the logout 
> command by dropping the HTTPS session, like the logout command 
> dropping the TLS connection on the server-side.  By not mixing the EPP 
> commands with the underlying transport, it was possible to configure 
> the transport (TLS or HTTPS) on the client-side, as was done in our 
> EPP SDK.  My recommendation is to ensure to keep the transport purely 
> a transport and not have the login command intermingled with the HTTPS 
> session.

[ML]  My opinion is that the approach described in the draft is still 
compliant with RFC 5730.

Section 2.9.1 states that the EPP command starting a session is <login> 
which appears to me also consistent with the fact that every session in 
a REST service is established after a successful authentication phase.

Neither It seems to me that the proposal mixes the EPP commands with the 
underlying transport. On the contrary, mapping an EPP session onto an 
HTTP session makes the application layer completely independent on the 
physical layer, for sure more independent than EPP over TCP.
> One other difference was the use of the media type “text/xml” instead 
> of defining a new one with “application/epp+xml”.
[ML] Just realized that the "application/epp+xml" was already defined by 
RFC 5730. I missed that . I'll remove the section regarding the media 
type from the document.
> The EPP packet length was set with the “Content-Length” header along 
> with relying on the HTTP keep-alive, which is consistent.

[ML] Don't think that strictly relying on the HTTP keep-alive feature is 
good, especially in a load balancing scheme.

Anyway, I have booked a slot at next meeting to present the proposal. So 
we can have time for a live discussion.

Best,

Mario

> -- 
>
> JG
>
>
>
>
> *James Gould
> *Fellow Engineer
> [email-masked] 
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
> *From: *regext <[email-masked]> on behalf of Mario Loffredo 
> <[email-masked]>
> *Date: *Wednesday, March 2, 2022 at 6:47 AM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[EXTERNAL] [regext] Fwd: New Version Notification for 
> draft-loffredo-regext-epp-over-http-00.txt
>
> Hi folks,
>
> Just posted a draft about EPP over HTTP.  It aims to define rules for 
> the EPP implementations leveraging HTTP due to its simplicity and ease 
> of use.
>
> Even if EPP is largely implemented over TCP, some HTTP based 
> implementations exist and a standardization would be advisable.
>
> *Oggetto: *
> *Data: *
> *Mittente: *
> [email-masked]
> *A: *
> Jan Romanowski <[email-masked]> 
> <mailto:[email-masked]>, Lorenzo Luconi Trombacchi 
> <[email-masked]> <mailto:[email-masked]>, 
> Lorenzo Trombacchi <[email-masked]> 
> <mailto:[email-masked]>, Marcin Machnio <[email-masked]> 
> <mailto:[email-masked]>, Mario Loffredo <[email-masked]> 
> <mailto:[email-masked]>, Maurizio Martinelli 
> <[email-masked]> <mailto:[email-masked]>
>
>
>
>
> URL: 
> https://www.ietf.org/archive/id/draft-loffredo-regext-epp-over-http-00.txt 
> <https://secure-web.cisco.com/1f30dq890q6OrF7oLq92m2FwCsaQYGofA9g5UVFZlHkmN0w_yAnbxq9DW0cng9yq1vWPgqDHusaG7I_pd7Fj4HY4k3E12N2lZ1KQR3XYcBxZ4Fuq9uL9cyPCZGPD3SOU9UVMWBvgLccCqeZcoPppgb79gEzOCSU6xUIxnQSxEIOdQ2IKNsK1iLRDUhVmqdA8sjpP4A2mavGo2L5DF-Rx07Nx3vWgTgiFN-5fKLapEn2ndXKhlxVnDE0uw7Et2CWck/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-loffredo-regext-epp-over-http-00.txt>
> Status: 
> https://datatracker.ietf.org/doc/draft-loffredo-regext-epp-over-http/ 
> <https://secure-web.cisco.com/1e-EzKBW4F-ke3YB-EbSecmjRZQjNyGt_AMB9DoqHhXoy2emw5WScEOrERmcHKLufTmxRFNsSsmi2oDZHMu2PosarH3O8FtwH1h7eWpFvAWPvg_TxYpepR-EMI0eWP6gZukKJFDy0UrW-9LO27dgrGaoRyo53ZYM_1bvPZL3semd5_mD2xUD09Tx-pBTyR3lqjDXTV2_g_62iZ27ixUHPJNt6mDbIwagHhxDOeQByS1qTEuJMznqU19N9rhdi_JV4/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-loffredo-regext-epp-over-http%2F>
> Htmlized: 
> https://datatracker.ietf.org/doc/html/draft-loffredo-regext-epp-over-http 
> <https://secure-web.cisco.com/1wiuZNeJDCZOU0TRLJxGBsMS3mMMkykHo-jJZpWgFbcjOdAwcTy9S0z2HvH9BdlOc063zPjm2eB0NDa3UBBVvNeZ3TdDbuj5ewbxTjc-VWO2ctIq10oOq_toZDXhDx-I469jfy6dBn3OxeBJfSQctig1xhdc5gOJlsHzlfbxkntqMg14jsEigdNdcXuV5YqBxO4d8vMNPugQX3z3bk-gE4ETukCyRhHsOIlM6DRumLe5OUtqKX74_yIT5Oc-ZoD0C/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-loffredo-regext-epp-over-http>
>
>
> Abstract:
-- 
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo

---

From: Mario Loffredo <[email-masked]>
Date: Wed, 2 Mar 2022 18:25:08 +0100

Hi Gavin,

please find my comments below.

> https://github.com/aeden/epp-over-http

I provided my feedback about that proposal. My main concern was about 
the fact that every EPP command required the registrar to be previously 
authenticated. It appeared to me inefficient iin general and 
particularly when a massive amount of request are sent to the server in 
a very short time.

In addition, it didn't seem to me in line with the trend in REST 
services to allow for work sessions consequent to a user authentication 
phase (see rdap-openid ).

>  From the security point of view, while EPP has a relatively small attack surface, if you're a registry, you're somewhat limited in terms of the third-party security services you can deploy to prot…

Thanks a lot for the hint about deploying EPP on a cloud environment. 
Both the registries implementing the draft haven't considered this 
scenario.  I'll include it in section 2 ;-)

Best,

Mario

> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

Web: http://www.iit.cnr.it/mario.loffredo