Subject: Re: [regext] Comments to the feedback about epp-over-http

From: "Gould, James" <[email-masked]>
Date: Wed, 30 Mar 2022 13:59:52 +0000

Mario,

I include my feedback embedded below.

--

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: Mario Loffredo <[email-masked]>
Date: Wednesday, March 30, 2022 at 8:28 AM
To: James Gould <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: [regext] Comments to the feedback about epp-over-http

Hi James,

my comments are embedded below.

Il 29/03/2022 17:50, Gould, James ha scritto:
Mario,

My responses are embedded below.

--

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://secure-web.cisco.com/1fmebMbwOUgdo-WyMaIsLZ1SH_XvKhWjFsvhnqk29yAQF2aCDU1bQl0rsVTtHPLG2BkDpIZ4MRjQsieE6r3TIX1L0ZZ7ekjXpaFeAZJDrC_Po6vguQRG0GQxM_3QyDX71rQvTjctNCis34Eb3FlrargkQgR5XO62fk7y3kgDfQM3nIcfYBm16faG667F4c9QVNETKgFbhSeqgY14mUJuMb_4AAv736hwPtIFaeVSRpYMMCGp1ZN1ut0cVsLLpuUa2/http%3A%2F%2Fverisigninc.com%2F>

From: Mario Loffredo <[email-masked]><mailto:[email-masked]>
Date: Tuesday, March 29, 2022 at 11:00 AM
To: James Gould <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: [EXTERNAL] Re: [regext] Comments to the feedback about epp-over-http

Hi James,
Il 29/03/2022 13:41, Gould, James ha scritto:
Mario,

My feedback is embedded below.

--

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://secure-web.cisco.com/1EaISbPmlOZzCKgUuIbmDA4rr-y-fT4gnfY0xiPotQBQC-vNT5PBKwJ1STPDcTK6y65BpvZgT5XqntG_ZysxPVZX8XjGyZXOW-P8nL-bdEwKNOkYvtyGhf1-PjTUP3gKykqkaX6QProvtyfCBkgC_m9J8xcE7yHeQ2_JycG85cc1JtO74KeQ6D9bsl9tHxNpgzRFA-IE_CZkI01GCY0-9LRrY2Tdd3mwPuBMAXYl7okYjJdszZFa2vwEdisCoAWAN/http%3A%2F%2Fverisigninc.com%2F>

From: Mario Loffredo <[email-masked]><mailto:[email-masked]>
Date: Monday, March 28, 2022 at 6:59 AM
To: James Gould <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: [EXTERNAL] Re: [regext] Comments to the feedback about epp-over-http

Hi James,

thanks for ypur quick reply.

Please find my comments below.
Il 25/03/2022 16:45, Gould, James ha scritto:
Mario,

For #4 “Cookie vs. HTTP Connection”, you asked the question “can you further clarify why we should opt for establishing the cookie at setup of the connection and how should it be possible? For example, what kind of request should be used to start the HTTP connection?”.

I implemented pluggable transports in the Verisign EPP SDK, which included HTTP, HTTPS, TCP, and TLS.  The Verisign EPP SDK does include a client interface as well as a server stub implementation, so I was able to see the transports from both sides.  Support for HTTP and HTTPS was removed once we stopped supporting EPP over HTTP.  The cookie is setup at the time of the HTTP or HTTPS connection.  There is no “request” that is used to start the HTTP connection, just like the case for TCP and TLS.  A network connection is made, which includes the underlying TLS handshake in the case of HTTPS and TLS and the cookie is setup for HTTP and HTTPS, and then the EPP application protocol rides on top of it.

It seems to me a very low-level implementation.

Sorry but I stiil don't understand how cookies are returned. They should be returned in an HTTP response that doesn't correspond to an HTTP request. Correct?

JG: HTTP is being defined as a transport for EPP, so it should be treated as such.  The setup and tear-down of the HTTP connection, includes the setup of the cookies that is used for HTTP session tracking.  When a connection is made to the EPP / HTTPS server, the TLS connection is first established via the TLS-handshake and the HTTP session is established via setup of the session cookie (e.g., JSESSIONID), which then enables the server to maintain state.  State such as tracking failed login attempts and timeouts (idle / command / absolute), which will result in a drop in the HTTP session / connection when the login attempt threshold is exceeded.  At the application layer, a HTTPS connection is treated in the same way as a TLS connection, where the transport handles the framing and the connection state, and the application layer returns the EPP Greeting when the connection is setup and drops the connection with a EPP logout occurs or other EPP session conditions (e.g., exceeding timeouts).  The HTTP session cookie is returned in all the HTTP responses.  There is absolutely no intermingling of the transport layer (HTTP) with the application layer (EPP) other than making a connection available to read and write framed packets and the ability to close the connection when needed.

If so, it seems to me uncompliant with what is stated in the first paragraph of Section 2.1 of RFC7230:

   HTTP is a stateless request/response protocol that operates by

   exchanging messages (Section 3<https://secure-web.cisco.com/1HLyHB_XdFEjfXQwGFkG0LZSLLnG4WFNvmZ-TNjfY6OfIaLTmL1biILbx72S_U5GmIiJtbpg0x39TJ52od6XvJJ-XGkebzBiEggAwQ42v85iZAXdc75eWbMUFwdy__GSQvGqoc_3jBcXvzaJksIZ9kIaGCObuN4sNz3NQqB4Gsr44Gdw9c4U6nDx9j_3kyp9hk3Za8zxK-CiPfgUAyNLhZ53ksc5Ae9PHvSSpW9kjbB9txLir0tvwL_pUPzDpJS2Y/https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7230%23section-3>) across a reliable transport- or

   session-layer "connection" (Section 6<https://secure-web.cisco.com/1vvJc-KSBR_KweDtRuo-dlLx6E_Z9fnj9TRqKJPKmI-z_MzpIyDJWDzfwvS180O64nU4M_K-HwHtvVlPkTyfnMVQ8I50S_dOCSrwzrW9QXz8ckfa9Yj0UZmgPk4aOBSCgpizCtKhPiufait2c-bik8SwDi5FGriXh2QetIDOP_N5qvkVGUCrJ7Agu0Kz55-5IRTrJpPK2rtdg6AYpfgj-5oaNCOjZ9kZcI233HN_HumLXDVcKmYklOTTqh_7mGPwt/https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7230%23section-6>).  An HTTP "client" is a

   program that establishes a connection to a server for the purpose of

   sending one or more HTTP requests.  An HTTP "server" is a program

   that accepts connections in order to service HTTP requests by sending

   HTTP responses.

JG: I don’t see how using HTTP as a EPP transport would be considered uncompliant with RFC7230.  Below is the flow of using HTTP as an EPP transport:
1.       Establish TCP connection
2.       Establish TLS session via TLS-handshake
3.       Establish HTTP session via setup of the HTTP session cookie (e.g., JSESSIONID)
4.       Return EPP Greeting in framed HTTP response with the session cookie (e.g., JSESSIONID)
5.       Support HTTP requests in the form of framed EPP commands that are returned in HTTP responses in the form of framed EPP responses.
6.       EPP session ends that drops the connection (HTTP / TLS / TCP)

[ML] I apologize James but I still don't understand how it would be possible to return an HTTP response including the EPP Greeting and establish a session cookie without having previously received an HTTP request or, to say it better, how it would be possible at the abstraction level provided by all the libraries and frameworks supporting HTTP communication on both client and server side.

Being HTTP used as a purely transport (L4) protocol but not as a request/response (L7) protocol,  the implementation wouldn't be compliant with RFC7230.

The same concept is also repeated in Section 2.1 of RFC 2818 "HTTP over TLS":

   The agent acting as the HTTP client should also act as the TLS

   client.  It should initiate a connection to the server on the

   appropriate port and then send the TLS ClientHello to begin the TLS

   handshake. When the TLS handshake has finished. The client may then

   initiate the first HTTP request.  All HTTP data MUST be sent as TLS

   "application data".  Normal HTTP behavior, including retained

   connections should be followed.

JG: The first step is a HTTP GET request that establishes the HTTP session and receives the EPP Greeting in the HTTP GET response, which includes the HTTP session cookie.  Subsequent requests can use a HTTP POST for the EPP command and receive the HTTPS POST response for the EPP response.  The EPP SDK Stub Server supported use of either the HTTP GET or POST and if a HTTP session did not exist, it returned the EPP Greeting in the HTTP response with the HTTP session cookie.  After the HTTP session was established, the responsibility of the HTTP layer was strictly to accept HTTP requests, which works as the packet framing of TCP, and places the EPP responses in the HTTP responses.  The HTTP request and response is fully compliance with the RFCs, since the connection is a request with a greeting response, and subsequent EPP command and responses are handled in HTTP requests and responses.  Connection state is maintained in the HTTP session, which would deal with issues like a failed login threshold and timeouts (idle and command).  The Verisign EPP SDK includes an packet assembler class, which is configurable, which deals with the marshaling and unmarshaling of the commands and responses of the underlying EPP transport, which included assemblers for TCP, TLS, HTTP, and HTTPS.  You could even setup client session pools using the assembler of your choice, where a single client could interface with an EPP/TLS server and an EPP/HTTPS server, all by specifying the desired EPP transport.  If you are to mix the EPP protocol with the underlying transport layer, then it would remove the ability to plug in the desired transport.

[ML] Now everything is clear to me. I didn't udenstrand your previous message because you omitted that a client starts the HTTP session via HTTP GET :-)

Both .it and .pl  implement only the POST method. HTTP and EPP sessions are started together and linked each other after a Login command due to the following reasons:

  1.  The session ID is the unique key to retrieve EPP session information

JG: That intermingles the application layer with the transport.  Do you support EPP / TLS in parallel with EPP / HTTPS?  If so, this intermingling would pose an issue.  The EPP session id should be independent of the HTTPS session id.

2) Except for the client IP address, the information that a server must maintain as long as an EPP session lives is included in the Login request (i.e. the registrar name and the XML namespaces)

3) It's very unlikely that an EPP client doesn't know the services provided by a given EPP server

JG: Does this mean that .it and .pl doesn’t provide the EPP Greeting when the connection is established?  Returning the EPP Greeting at the time of connection is a requirement in RFC 5730 “An EPP server MUST respond to client-initiated communication (which can be either a lower-layer connection request or an EPP service discovery message) by returning a greeting to a client.”.

4) As a consequence of point 2 and 3, why should a client submit a meaningless HTTP request to the server before submitting the Login command  to start an EPP session?

JG: The EPP transport needs to support what is defined in RFC 5730.  The connection is established and the server returns an EPP Greeting.

5) RFC5730 states that an EPP session starts with a <Login> command and RFC6265 states that servers maintain stateful sessions over HTTP by setting the session cookie. Hence, It seems natural to me that servers start an HTTP session  and set the session ID after a successful Login command.

JG: The EPP session may start with the login command, but the transport session is established ahead of the EPP session being established.

6) Application protocol sessions on server side normally start after authenticating the client (please note that this is exactly what we are pursuing in RDAP)

JG: You really need to follow the flow defined in RFC 5730 for an EPP transport.  My recommendation again is to set the HTTP session id at the time of the connection and have the server return the EPP Greeting, just like what occurs with EPP over TLS.  The transport should not intermingle with the application protocol, which enables the pluggable of transports on the client-side and the server-side.

7) It seems inefficient to release an HTTP session from an EPP session because it can result in wasting resources to maintain possible useless HTTP sessions.

JG: I don’t see the wasting resource use case here.  When a client makes an EPP over HTTPS connection to the server, the HTTP session is established and EPP rides on top of it.  The first EPP packet sent is the EPP Greeting by the server.  The server can establish policies such as maximum failed login attempts to drop the connection.

8) If an HTTP session is not established after an authentication, IP whitelisting is a must instead of a recommendation. Even if in general registries require registrars to declare their own clients' IP addresses out-of-band, this is not an absolute constraint and the same IP address might be used by multiple registrars. For the same reason, you cannot limit the number of HTTP sessions per registrar thus mitigating the risks pointed out in point 7.

JG: IP whilelisting can be aggregated in the ACL and then checked during the login command.

Regarding to the EPP commands, other than Hello and Login, that don't include a valid session ID,  think it's better the server returns an EPP error ("Command use error") instead of a Greeting response including a new session ID.

JG: If you’re not returning the EPP Greeting at the time of the connection, you’re not implementing EPP.  The definition of an EPP transport needs to fully support the EPP protocol defined in RFC 5730.

Have a question: how do you figure out the case where a client issues two Login commands with the same valid session ID previously received via the GET response? I imagine that only one would be accepted.

If so, the mapping between an HTTP session and EPP session exists also in your implementation. It occurs when the EPP session is created instead of when the HTTP session is created.

JG: The HTTP session maps to the state held on the server-side, which would include items like the client IP address, client certificate, and other attributes that can be used along with the passed user name and password in the login command.  The EPP HTTP transport should handle the same features as EPP TCP in RFC 5734, which includes the connection requirements (e.g., TLS) and the method of packet framing.  In the case of HTTP, there is the need for establishing the HTTP Session Id and using the HTTP request and response packets for containing / framing the EPP packets.

Best,

Mario

7.

Anyway, the approach normally followed by every HTTP implementer leverages the services provided by an application server that incorporates an HTTP server.

You don't need to manage HTTP connections, HTTP resquest/response marhsalling/unmarshalling and other low-level details. You just need to focus on the core of your server.

Similarly, on the other side side, after having configured an HTTP client instance, a client simply builds and sends an HTTP request, and  then receives and processes an HTTP response.

JG: An EPP client or server should be capable of reusing all the same command and response processing without dealing with transport specific logic.  The transport layer can be built as a layer that is pluggable.  A client can configure the transport to use on a per-server basis, and the server can reuse the same command processing logic whether running on top of TLS or HTTPS, since TLS and HTTPS are purely transports.

[ML] It's unclear to me how two communications working at different layers could be handled in the same way. As I wrote in my previous reply to Matthias, the approach proposed aims to preserve EPP commands semantics so that the EPP server core should be the same regardless the fact that it is supported by HTTP or TCP.

JG: It's very straight forward to make the EPP transport pluggable if you treat the EPP transport as purely a transport.  The application layer does need to go through a pluggable transport layer to enable the transport layer to frame, and marshal/unmarshal the commands and responses.  In the case of the Verisign EPP SDK, that assembler layer took care of it for TCP, TLS, HTTP, and HTTPS.  The EPP command processing is not dependent on the transport layer, meaning the EPP command processing layer doesn’t need to be concerned with setting a HTTP session cookie upon a successful EPP Login or handling the EPP Hello in any special way as it relates to HTTP cookies.  EPP is a stateful protocol, where the underlying transport needs to support being stateful.  If the desire was to move towards stateless, then you’re not defining an EPP transport but a new EPP protocol.  My recommendation is to keep the EPP over HTTP simple and establish the HTTP cookie at the setup of the HTTP connection and separate the EPP sessions from the HTTP session.

Mario
If there is a HTTP transport for EPP, then it should be purely a transport and not intermingle with the application protocol.  There is no need to directly tie a HTTP session with the established EPP session.  By keeping them separate, it makes it much easier for the client and the server to have pluggable transports, where the processing of the EPP commands including the hello, login, and logout treat the transport as simply a connection with no intermingling of session management.

If it means that you have to reimplement what has commonly been used for years, it isn't clear to me how it could be much easier. On the contrary, it seems to me much trickier, especially if you implement EPP-over-HTTP from scratch.

If the goal is using the same approach for mapping every transport layer without considering the peculiarites of each transport protocol and the technology the implementers are accostumed to use to deal with them, it doesn't make sense to me.

For example, I cannot figure out how HTTP load balancing could support your solution.

JG: The HTTP transport for EPP can easily be defined as a pure transport, which provides a connection for the application layer to leverage in the same fashion as TLS.  The load balancer can leverage the TLS session id to route to the EPP gateway and in the case of HTTP, the HTTP session can be used to route the request to the appropriate application server that contains the connection state.  Some HTTP application server proxies leverage the HTTP session to route the requests to the application server that contains the HTTP session and state.  You need to establish the HTTP session when the connection is established to support the needed routing.  There are other load balancing options, but by simplifying EPP over HTTP to have HTTP as purely a transport, it provides maximum flexibility in routing and maximum pluggability of transports (TCP, TLS, HTTP, HTTPS).

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://secure-web.cisco.com/1ojxKstUEceETR7pe4khQ2dcwgGUwoOuZu4vhcT-TZcTCCpM93jXl6eq5i46tfTPt6lE9M6FO7hPqFZQVgxN5su1ozpEIXrOmp6SzB5kEB5SXCcRaJIg-vRb2B_SxGeDcgjxTqmZNEVO_Z0LtwZEFTLbzsLhmMMT-MlZ9pX7rpBY6Q8K0RxXyklhUEXCOqlJ0RMcZX2tEZNHp0Pr6XFhgw4X7OA0XCs0tk_jqiJbYMrkAFF0PXiAItfCmm_MR8whC/http%3A%2F%2Fverisigninc.com%2F>

From: regext <[email-masked]><mailto:[email-masked]> on behalf of Mario Loffredo <[email-masked]><mailto:[email-masked]>
Date: Friday, March 25, 2022 at 11:01 AM
To: "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: [EXTERNAL] [regext] Comments to the feedback about epp-over-http

Hi folks,

here are in the following some comments grouped by subject to last meeting's feedback about EPP-over-HTTP:

1) Draft title

Ulrich suggested to call the document EPP-over-HTTPS.

I replied that the name was assigned to be consistent with RFC5734, i.e. EPP-over-TCP.

SImilarly to RFC5734, the draft states, first in the abstract and then in the security considerations, that TLS is required.

That being said, the authors don't object to renaming the dcocument EPP-over-HTTPS if the WG agrees.

2)  Cookies

Jim (Reed) asked why cookies should be used in this case.

The reasons why we have used session cookiea are that they represent a standard method (RFC6265), well known to the community of REST service implementers, largely used and natively supported by libraries and frameworks on both client and server side. For example, it is the same method used by rdap-openid to map an RDAP session and tie it to an access token :-)

.it and .pl have been using this method since the beginning and the registrars, after being informed that they had to enable cookies in their HTTP clients, have no longer complained about cookie management.
In addition, the implementation of such a method doesn't  introduce any change to the EPP core spec. Indeed, it preserves EPP comands semantics and doesn't mix the application layer with the transport layer.

I would like to say that, regarding the clear distinction between those layers, this proposal is even better than RFC5734 as every EPP response is returned by the server as a consequence of receiving an EPP request.

On the contrary, in RFC5734, an EPP <greeting> is returned to the client after the TCP connection has been established so, at least in this case, the two layers get mixed.

Which method other than session cookie shoud be used instead ?

3)   Security Considerations

Ulirch recommended to review the security considerations by inheriting those from TLS WG about which versions and ciphers of TLS to use.

Thanks a lot for the heads up, Ulrich. Surely, we'll do.

Gavin noted that, unlike EPP-over-TCP, this draft states that client IP address check is optional.

As a matter of fact, it is stated as recommended.

Anyway, the authors don't object to changing it into an absolute rquirement if the WG agrees.

4)  Cookie vs. HTTP Connection

One comment from James in the chat is about establishing the cookie at setup of the connection and not linking it to the EPP Login command.
James, can you further clarify why we should opt for establishing the cookie at setup of the connection and how shoudl it be possible? For example, what kind of request should be used to start the HTTP connection?

IMO, an HTTP session is something that is inherently unlinked to the HTTP connections.

HTTP connections can be broken but sessions don't get lost.

Programmatically, REST implementers are in charge of processing HTTP requests and building responses rather than managing HTTP connections, which is instead delegated to the application servers.

Finally, I would like to outline that Section 2.9.1 of RFC5730 states that an EPP session starts with a Login command and the mechanism described by RFC6265 lets (I'm quoting here) "the servers maintain a stateful session over the mostly stateless HTTP protocol". As a consequence, it seems much more practical to start the EPP/HTTP session as a result of a Login command.

5) EPP/HTTP Sessions vs. HTTP3 Connections

Ulrich remarked that, in HTTP3, it is possible to have multiple sessions on an HTTP connection.

This is valid also for the other HTTP versions.

In fact, an HTTP connection can be kept alive and, over it, a client could submit multiple login-commands-logout sequences.

This is quite usual for a smart client managing a pool of HTTP connections.

Instead, It is unlikely but not impossible to come across HTTP connections supporting multiple concurrent sessions.

What should be the possible drawbacks for a server in allowing the scenarios above?

6) Client authentication in HTTP3

Another note pointed out that HTTP3 client authentication requirements are different from this draft and they need to be reconciled.

Think that it could be sufficient to add to the security considerations some text similar to what is included in section 4.4 "Peer authentication" of RFC 9001 "Using TLS to secure QUIC":

   A client MUST authenticate the identity of the server.  This

   typically involves verification that the identity of the server is

   included in a certificate and that the certificate is issued by a

   trusted entity (see for example [RFC2818<https://secure-web.cisco.com/1tkPqD6aAMfTp6t6KppHDGdn0xpgOWSMeCqwZR-hs9Duph9SiceA0vCbaJJVqywNzcZscc6vUZkCPH9lCdtXq_nVJ3OfnNMz-XTQvhBuSBLsXa0VfO5ZNrGo47fSin8GRaQOWRSvSQP_7vRecBdddhF6L0Yqx3KcxAGpvdxpFCsPhLcd5bm-aVy3vTko6TfGBlohe2XEw3bwUmH-u56ZuZz50CUXUqA3YDFgBENAwPrLBjwdDxwgG1JFVGPZF_LEQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc2818>]).

The draft has only considered the optional use of a certificate on server side (not on client side). In doing that, the draft is consistent with another sentence in the same paragraph of RFC9001:

   A server MAY request that the client authenticate during the

   handshake.  A server MAY refuse a connection if the client is unable

   to authenticate when requested.

Would it address the feedback?

That's all for now.

Hope I did not miss anything.

Thanks a lot for your interest and feedback.

Looking forward to your further comments.

Best,

Mario

--

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<http://secure-web.cisco.com/1Af0lIvD4wj2TkngfEVwrFVEVRozLiVIU2m1Gi1AH1GN4-eWP-IREXsOLCh8OJ03YAxRNYqVCPHQSwgj-tMCyzvN3jokOBTIBx4-5n1pJdiRXxl-ShJCaHkCjGNPa8EA5qw4kPjkxIrFAy1qOTcPFhieqdc_xyu8yisYoXzily9ozVw3GZaUtkKrLnmnDJhlFv2LRTCTnw913LzH8bX-hB6FpPlyFi_0v2_H1NFCgZYjuu4pgUeOeIqQJRQwtzNLS/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>

--

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<http://secure-web.cisco.com/1OpUT5efcRPCKu9ZmpfyFmbeoIexTqMIlduFKl7VTUSeET1W3oogufCAfJPPw-WSQ0iyo_wkztY_7M69qw0yf13C4w7OWB_Zk5w2FsV-GGCSLot8lFQdslU0DvCpCTw9FjZr0AsFsubGH-kToYrLxzzEj7vGDKuxIFxPK92P5bu2CDOE4UFtRPRGvu9rzX83rks8X2le_j1uSS1SD5B8CyvSp0tsne0HWMS5luho_DIhdOil7-0a_7ZX6CQA08GQq/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>

_______________________________________________

regext mailing list

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

https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/16jl36WEWq0s-czRNUY5mezogTB1s8eM6-POsf3osvBxTtShse2Gx3vayC92AUxQ8ebDwE9Ob8SzhMcrkTCHnZy_RbpQlkSPKyyG9v1LOvWmmr2bX-q2Kwz-52tKvzlBlfgMU_rKnCsIFS9e53n9Fl1sqideuhzE2Qvq05_MQ6tGzuKP1z0P4vYyDR8QmVl4xwlz-BKFhZLijpQYz9CLe61qg3JAC0a2ldUiZMLUwjnSSssMNXvvVibSRdv-9l9yg/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>

--

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<http://secure-web.cisco.com/1yKvefSSzzB1xtPf0Zt9UvXnOkA28n5LvF1HkMnNZqV6Dwz7x7ZD06GbmS94ZAQwsmSA6iszQPAkGi5fNCSMjCHwEbful0vNQc0bfu7a2ydpIkKyqCYgjHlBp7I_-3eCZXAtMTjU_xfTEae9EnXNbksctYNkGyOsHDR02jSoOeVLa3lgW8hWUZ20zgxxFQlt_HdsERDtOQY4EoiE3orLFHDV3wtSA-ChHIYVp1pfMvU2aCEBQ3tWEhFOLp740jUPP/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>

--

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<http://secure-web.cisco.com/1pp2UVbYq0m0PdgNAIf-MFBBPlI6rgwJb-nl0OyxKTaZvJklLUlXEVPn3qvn6ziLbUr86nSYHSn9PLRlT1wKKUgtGjJOdnJ8Ghkk3hlYjxMa4J4AaIOBZ7WvzWPIEvoHPBVb2TdHFIKvtiJkT5ev0nRTy-ErBgM9XRxiNe_p-wkwdeLKKqJWcyzpKSrlr3WZKQaTzmyHAwtIPMymiYesdU2YUhfSeGkOO4qysnLCFQpp6nqMFwr28xmvjE8p7Rz8v/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>

---

From: Mario Loffredo <[email-masked]>
Date: Wed, 30 Mar 2022 19:07:46 +0200

Hi James,

here are again my responses below.

Il 30/03/2022 15:59, Gould, James ha scritto:
> *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: *Mario Loffredo <[email-masked]>
> *Date: *Wednesday, March 30, 2022 at 8:28 AM
> *To: *James Gould <[email-masked]>, "[email-masked]" 
> <[email-masked]>
> *Subject: *[EXTERNAL] Re: [regext] Comments to the feedback about 
> epp-over-http
>
> Hi James,
>
>     *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://secure-web.cisco.com/1fmebMbwOUgdo-WyMaIsLZ1SH_XvKhWjFsvhnqk29yAQF2aCDU1bQl0rsVTtHPLG2BkDpIZ4MRjQsieE6r3TIX1L0ZZ7ekjXpaFeAZJDrC_Po6vguQRG0GQxM_3QyDX71rQvTjctNCis34Eb3FlrargkQgR5XO62fk7y3kgDfQM3nIcfYBm16faG667F4c9QVNETKgFbhSeqgY14mUJuMb_4AAv736hwPtIFaeVSRpYMMCGp1ZN1ut0cVsLLpuUa2/http%3A%2F%2Fverisigninc.com%2F>
>
>     *From: *Mario Loffredo <[email-masked]>
>     <mailto:[email-masked]>
>     *Date: *Tuesday, March 29, 2022 at 11:00 AM
>     *To: *James Gould <[email-masked]>
>     <mailto:[email-masked]>, "[email-masked]"
>     <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>
>     *Subject: *[EXTERNAL] Re: [regext] Comments to the feedback about
>     epp-over-http
>
>     Hi James,
>
>         *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://secure-web.cisco.com/1EaISbPmlOZzCKgUuIbmDA4rr-y-fT4gnfY0xiPotQBQC-vNT5PBKwJ1STPDcTK6y65BpvZgT5XqntG_ZysxPVZX8XjGyZXOW-P8nL-bdEwKNOkYvtyGhf1-PjTUP3gKykqkaX6QProvtyfCBkgC_m9J8xcE7yHeQ2_JycG85cc1JtO74KeQ6D9bsl9tHxNpgzRFA-IE_CZkI01GCY0-9LRrY2Tdd3mwPuBMAXYl7okYjJdszZFa2vwEdisCoAWAN/http%3A%2F%2Fverisigninc.com%2F>
>
>         *From: *Mario Loffredo <[email-masked]>
>         <mailto:[email-masked]>
>         *Date: *Monday, March 28, 2022 at 6:59 AM
>         *To: *James Gould <[email-masked]>
>         <mailto:[email-masked]>, "[email-masked]"
>         <mailto:[email-masked]> <[email-masked]>
>         <mailto:[email-masked]>
>         *Subject: *[EXTERNAL] Re: [regext] Comments to the feedback
>         about epp-over-http
>
>         Hi James,
>
>             For #4 “Cookie vs. HTTP Connection”, you asked the
>             question “can you further clarify why we should opt for
>             establishing the cookie at setup of the connection and how
>             should it be possible? For example, what kind of request
>             should be used to start the HTTP connection?”.
>
>             I implemented pluggable transports in the Verisign EPP
>             SDK, which included HTTP, HTTPS, TCP, and TLS.  The
>             Verisign EPP SDK does include a client interface as well
>             as a server stub implementation, so I was able to see the
>             transports from both sides.  Support for HTTP and HTTPS
>             was removed once we stopped supporting EPP over HTTP.  The
>             cookie is setup at the time of the HTTP or HTTPS
>             connection.  There is no “request” that is used to start
>             the HTTP connection, just like the case for TCP and TLS. 
>             A network connection is made, which includes the
>             underlying TLS handshake in the case of HTTPS and TLS and
>             the cookie is setup for HTTP and HTTPS, and then the EPP
>             application protocol rides on top of it.
>
>         Sorry but I stiil don't understand how cookies are returned.
>         They should be returned in an HTTP response that doesn't
>         correspond to an HTTP request. Correct?
>
>         JG: HTTP is being defined as a transport for EPP, so it should
>         be treated as such.  The setup and tear-down of the HTTP
>         connection, includes the setup of the cookies that is used for
>         HTTP session tracking. When a connection is made to the EPP /
>         HTTPS server, the TLS connection is first established via the
>         TLS-handshake and the HTTP session is established via setup of
>         the session cookie (e.g., JSESSIONID), which then enables the
>         server to maintain state.  State such as tracking failed login
>         attempts and timeouts (idle / command / absolute), which will
>         result in a drop in the HTTP session / connection when the
>         login attempt threshold is exceeded.  At the application
>         layer, a HTTPS connection is treated in the same way as a TLS
>         connection, where the transport handles the framing and the
>         connection state, and the application layer returns the EPP
>         Greeting when the connection is setup and drops the connection
>         with a EPP logout occurs or other EPP session conditions
>         (e.g., exceeding timeouts).  The HTTP session cookie is
>         returned in all the HTTP responses. There is absolutely no
>         intermingling of the transport layer (HTTP) with the
>         application layer (EPP) other than making a connection
>         available to read and write framed packets and the ability to
>         close the connection when needed.
>
>         If so, it seems to me uncompliant with what is stated in the
>         first paragraph of Section 2.1 of RFC7230:
>
>             exchanging messages (Section 3  <https://secure-web.cisco.com/1HLyHB_XdFEjfXQwGFkG0LZSLLnG4WFNvmZ-TNjfY6OfIaLTmL1biILbx72S_U5GmIiJtbpg0x39TJ52od6XvJJ-XGkebzBiEggAwQ42v85iZAXdc75eWbMUFwdy__GSQvGqoc_3jBcXvzaJksIZ9kIaGCObuN4sNz3NQqB4Gsr44Gdw9c4U6nDx9j_3kyp9hk3Za8zxK-CiPfgUAyNLhZ53ksc5Ae9PHvSSpW9kjbB9txLir0tvwL_pUPzDpJS2Y/https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7230%23section-3>) across a reliable transport- or
>
>             session-layer "connection" (Section 6  <https://secure-web.cisco.com/1vvJc-KSBR_KweDtRuo-dlLx6E_Z9fnj9TRqKJPKmI-z_MzpIyDJWDzfwvS180O64nU4M_K-HwHtvVlPkTyfnMVQ8I50S_dOCSrwzrW9QXz8ckfa9Yj0UZmgPk4aOBSCgpizCtKhPiufait2c-bik8SwDi5FGriXh2QetIDOP_N5qvkVGUCrJ7Agu0Kz55-5IRTrJpPK2rtdg6AYpfgj-5oaNCOjZ9kZcI233HN_HumLXDVcKmYklOTTqh_7mGPwt/https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7230%23section-6>).*An HTTP "client" is a*
>
>         *   program that establishes a connection to a server for the
>         purpose of*
>
>         *   sending one or more HTTP requests.*   *An HTTP "server" is a program*
>
>         *   that accepts connections in order to service HTTP requests
>         by sending*
>
>         *   HTTP responses.*
>
>         JG: I don’t see how using HTTP as a EPP transport would be
>         considered uncompliant with RFC7230.  Below is the flow of
>         using HTTP as an EPP transport:
>
>         1.Establish TCP connection
>
>         2.Establish TLS session via TLS-handshake
>
>         3.Establish HTTP session via setup of the HTTP session cookie
>         (e.g., JSESSIONID)
>
>         4.Return EPP Greeting in framed HTTP response with the session
>         cookie (e.g., JSESSIONID)
>
>         5.Support HTTP requests in the form of framed EPP commands
>         that are returned in HTTP responses in the form of framed EPP
>         responses.
>
>         6.EPP session ends that drops the connection (HTTP / TLS / TCP)
>
>     [ML] I apologize James but I still don't understand how it would
>     be possible to return an HTTP response including the EPP Greeting
>     and establish a session cookie without having previously received
>     an HTTP request or, to say it better, how it would be possible at
>     the abstraction level provided by all the libraries and frameworks
>     supporting HTTP communication on both client and server side.
>
>     Being HTTP used as a purely transport (L4) protocol but not as a
>     request/response (L7) protocol,  the implementation wouldn't be
>     compliant with RFC7230.
>
>         handshake.*When the TLS handshake has finished. The client may then*
>
>     *   initiate the first HTTP request.*   All HTTP data MUST be sent as TLS
>
>     JG: The first step is a HTTP GET request that establishes the HTTP
>     session and receives the EPP Greeting in the HTTP GET response,
>     which includes the HTTP session cookie.  Subsequent requests can
>     use a HTTP POST for the EPP command and receive the HTTPS POST
>     response for the EPP response.  The EPP SDK Stub Server supported
>     use of either the HTTP GET or POST and if a HTTP session did not
>     exist, it returned the EPP Greeting in the HTTP response with the
>     HTTP session cookie.  After the HTTP session was established, the
>     responsibility of the HTTP layer was strictly to accept HTTP
>     requests, which works as the packet framing of TCP, and places the
>     EPP responses in the HTTP responses.  The HTTP request and
>     response is fully compliance with the RFCs, since the connection
>     is a request with a greeting response, and subsequent EPP command
>     and responses are handled in HTTP requests and responses. 
>     Connection state is maintained in the HTTP session, which would
>     deal with issues like a failed login threshold and timeouts (idle
>     and command).  The Verisign EPP SDK includes an packet assembler
>     class, which is configurable, which deals with the marshaling and
>     unmarshaling of the commands and responses of the underlying EPP
>     transport, which included assemblers for TCP, TLS, HTTP, and
>     HTTPS.  You could even setup client session pools using the
>     assembler of your choice, where a single client could interface
>     with an EPP/TLS server and an EPP/HTTPS server, all by specifying
>     the desired EPP transport.  If you are to mix the EPP protocol
>     with the underlying transport layer, then it would remove the
>     ability to plug in the desired transport.
>
> [ML] Now everything is clear to me. I didn't udenstrand your previous 
> message because you omitted that a client starts the HTTP session via 
> HTTP GET :-)
>
> Both .it and .pl  implement only the POST method. HTTP and EPP 
> sessions are started together and linked each other after a Login 
> command due to the following reasons:
>
> JG: That intermingles the application layer with the transport.  Do 
> you support EPP / TLS in parallel with EPP / HTTPS?  If so, this 
> intermingling would pose an issue.  The EPP session id should be 
> independent of the HTTPS session id.
>
[ML] If I'm sure to generate every time a unique session ID, it doesn't 
matter if I support EPP/TLS together with EPP/HTTPS or not. It will be 
unique anyway. Don't understand why I should generate two unique session 
IDs, one to be used as session cookie and one to be used as EPP session 
identifier and then link them together ?!
>
> 2) Except for the client IP address, the information that a server 
> must maintain as long as an EPP session lives is included in the Login 
> request (i.e. the registrar name and the XML namespaces)
>
> JG: Does this mean that .it and .pl doesn’t provide the EPP Greeting 
> when the connection is established?  Returning the EPP Greeting at the 
> time of connection is a requirement in RFC 5730 “An EPP server MUST 
> respond to client-initiated communication (which can be either a 
> lower-layer connection request or an EPP service discovery message) by 
> returning a greeting to a client.”.
[ML] Since RFC5730 states that Greeting can be returned in response to 
an Hello either, we are compliant.
>
> 4) As a consequence of point 2 and 3, why should a client submit a 
> meaningless HTTP request to the server before submitting the Login 
> command  to start an EPP session?
>
> JG: The EPP transport needs to support what is defined in RFC 5730.  
> The connection is established and the server returns an EPP Greeting.
>
[ML] The HTTP connection might be established at any HTTP request the 
EPP client sends to the EPP server. If the interval between two 
subsequent HTTP requests exceeds the Keep-Alive timeout set b the HTTP 
server, the HTTP connection is established again. The session cookie is 
the mechanism that allows an HTTP-based EPP server to trace all the HTTP 
requests back to an EPP session.

An HTTP-based EPP server is able to manage requests, responses and 
sessions. It cannot manage connections because they are managed 
automatically at a lower layer.

> 5) RFC5730 states that an EPP session starts with a <Login> command 
> and RFC6265 states that servers maintain stateful sessions over HTTP 
> by setting the session cookie. Hence, It seems natural to me that 
> servers start an HTTP session  and set the session ID after a 
> successful Login command.
>
> JG: The EPP session may start with the login command, but the 
> transport session is established ahead of the EPP session being 
> established.
>
[ML] In HTTP, a physical transport session doesn't exist. The stateful 
session is simulated via the session cookie over single HTTP 
connections. If the Keep-Alive is on, a TCP connection can be reused to 
issue multiple HTTP requests.

But this is not guaranteed.

> 6) Application protocol sessions on server side normally start after 
> authenticating the client (please note that this is exactly what we 
> are pursuing in RDAP)
>
> JG: You really need to follow the flow defined in RFC 5730 for an EPP 
> transport.  My recommendation again is to set the HTTP session id at 
> the time of the connection and have the server return the EPP 
> Greeting, just like what occurs with EPP over TLS.  The transport 
> should not intermingle with the application protocol, which enables 
> the pluggable of transports on the client-side and the server-side.
>
> 7) It seems inefficient to release an HTTP session from an EPP session 
> because it can result in wasting resources to maintain possible 
> useless HTTP sessions.
>
> JG: I don’t see the wasting resource use case here. When a client 
> makes an EPP over HTTPS connection to the server, the HTTP session is 
> established and EPP rides on top of it.  The first EPP packet sent is 
> the EPP Greeting by the server.  The server can establish policies 
> such as maximum failed login attempts to drop the connection.
>
[ML] So could a client send tons of HTTP GET without being blocked?

> 8) If an HTTP session is not established after an authentication, IP 
> whitelisting is a must instead of a recommendation. Even if in general 
> registries require registrars to declare their own clients' IP 
> addresses out-of-band, this is not an absolute constraint and the same 
> IP address might be used by multiple registrars. For the same reason, 
> you cannot limit the number of HTTP sessions per registrar thus 
> mitigating the risks pointed out in point 7.
>
[ML] See my previous comment.
>
> Regarding to the EPP commands, other than Hello and Login, that don't 
> include a valid session ID,  think it's better the server returns an 
> EPP error ("Command use error") instead of a Greeting response 
> including a new session ID.
>
> JG: If you’re not returning the EPP Greeting at the time of the 
> connection, you’re not implementing EPP.  The definition of an EPP 
> transport needs to fully support the EPP protocol defined in RFC 5730.
>
[ML] This is exactly what happens also in your implementation. An HTTP 
connection can be established by issuing an HTTP GET but it might happen 
that a new one is established by issuing the subsequent POST for the 
Login command.

In the first case, your server returns a Greeting response while in the 
second your server retuns the Login response. In both cases, a new HTTP 
connection is created.

Even if you set the EPP session timeout equals to the Keep-Alive 
timeout, you can be sure that two subsequent requests are using the same 
HTTP connection.

You can realize that if you control the HTTP connections but these means 
that you are working at a programming level that doesn't correspond to 
that provided by libraries and frameworks supporting HTTP on both client 
and server side.

My personal opinion is that such an interpretation of EPP over HTTP is 
actually impractical.

> Have a question: how do you figure out the case where a client issues 
> two Login commands with the same valid session ID previously received 
> via the GET response? I imagine that only one would be accepted.
>
> If so, the mapping between an HTTP session and EPP session exists also 
> in your implementation. It occurs when the EPP session is created 
> instead of when the HTTP session is created.
>
> JG: The HTTP session maps to the state held on the server-side, which 
> would include items like the client IP address, client certificate, 
> and other attributes that can be used along with the passed user name 
> and password in the login command.  The EPP HTTP transport should 
> handle the same features as EPP TCP in RFC 5734, which includes the 
> connection requirements (e.g., TLS) and the method of packet framing.  
> In the case of HTTP, there is the need for establishing the HTTP 
> Session Id and using the HTTP request and response packets for 
> containing / framing the EPP packets.
>
[ML] Why should a client certificate be stored in the EPP session?

Best

Mario

> Best,
>
> Mario
>
>         7.
>
>         Anyway, the approach normally followed by every HTTP
>         implementer leverages the services provided by an application
>         server that incorporates an HTTP server.
>
>         You don't need to manage HTTP connections, HTTP
>         resquest/response marhsalling/unmarshalling and other
>         low-level details. You just need to focus on the core of your
>         server.
>
>         Similarly, on the other side side, after having configured an
>         HTTP client instance, a client simply builds and sends an HTTP
>         request, and  then receives and processes an HTTP response.
>
>         JG: An EPP client or server should be capable of reusing all
>         the same command and response processing without dealing with
>         transport specific logic.  The transport layer can be built as
>         a layer that is pluggable.  A client can configure the
>         transport to use on a per-server basis, and the server can
>         reuse the same command processing logic whether running on top
>         of TLS or HTTPS, since TLS and HTTPS are purely transports.
>
>     [ML] It's unclear to me how two communications working at
>     different layers could be handled in the same way. As I wrote in
>     my previous reply to Matthias, the approach proposed aims to
>     preserve EPP commands semantics so that the EPP server core should
>     be the same regardless the fact that it is supported by HTTP or TCP.
>
>     JG: It's very straight forward to make the EPP transport pluggable
>     if you treat the EPP transport as purely a transport.  The
>     application layer does need to go through a pluggable transport
>     layer to enable the transport layer to frame, and
>     marshal/unmarshal the commands and responses.  In the case of the
>     Verisign EPP SDK, that assembler layer took care of it for TCP,
>     TLS, HTTP, and HTTPS.  The EPP command processing is not dependent
>     on the transport layer, meaning the EPP command processing layer
>     doesn’t need to be concerned with setting a HTTP session cookie
>     upon a successful EPP Login or handling the EPP Hello in any
>     special way as it relates to HTTP cookies.  EPP is a stateful
>     protocol, where the underlying transport needs to support being
>     stateful.  If the desire was to move towards stateless, then
>     you’re not defining an EPP transport but a new EPP protocol.  My
>     recommendation is to keep the EPP over HTTP simple and establish
>     the HTTP cookie at the setup of the HTTP connection and separate
>     the EPP sessions from the HTTP session.
>
>     Mario
>
>             If there is a HTTP transport for EPP, then it should be
>             purely a transport and not intermingle with the
>             application protocol.  There is no need to directly tie a
>             HTTP session with the established EPP session.  By keeping
>             them separate, it makes it much easier for the client and
>             the server to have pluggable transports, where the
>             processing of the EPP commands including the hello, login,
>             and logout treat the transport as simply a connection with
>             no intermingling of session management.
>
>         If it means that you have to reimplement what has commonly
>         been used for years, it isn't clear to me how it could be much
>         easier. On the contrary, it seems to me much trickier,
>         especially if you implement EPP-over-HTTP from scratch.
>
>         If the goal is using the same approach for mapping every
>         transport layer without considering the peculiarites of each
>         transport protocol and the technology the implementers are
>         accostumed to use to deal with them, it doesn't make sense to me.
>
>         JG: The HTTP transport for EPP can easily be defined as a pure
>         transport, which provides a connection for the application
>         layer to leverage in the same fashion as TLS.  The load
>         balancer can leverage the TLS session id to route to the EPP
>         gateway and in the case of HTTP, the HTTP session can be used
>         to route the request to the appropriate application server
>         that contains the connection state.  Some HTTP application
>         server proxies leverage the HTTP session to route the requests
>         to the application server that contains the HTTP session and
>         state.  You need to establish the HTTP session when the
>         connection is established to support the needed routing. 
>         There are other load balancing options, but by simplifying EPP
>         over HTTP to have HTTP as purely a transport, it provides
>         maximum flexibility in routing and maximum pluggability of
>         transports (TCP, TLS, HTTP, HTTPS).
>
>         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://secure-web.cisco.com/1ojxKstUEceETR7pe4khQ2dcwgGUwoOuZu4vhcT-TZcTCCpM93jXl6eq5i46tfTPt6lE9M6FO7hPqFZQVgxN5su1ozpEIXrOmp6SzB5kEB5SXCcRaJIg-vRb2B_SxGeDcgjxTqmZNEVO_Z0LtwZEFTLbzsLhmMMT-MlZ9pX7rpBY6Q8K0RxXyklhUEXCOqlJ0RMcZX2tEZNHp0Pr6XFhgw4X7OA0XCs0tk_jqiJbYMrkAFF0PXiAItfCmm_MR8whC/http%3A%2F%2Fverisigninc.com%2F>
>
>             *From: *regext <[email-masked]>
>             <mailto:[email-masked]> on behalf of Mario
>             Loffredo <[email-masked]>
>             <mailto:[email-masked]>
>             *Date: *Friday, March 25, 2022 at 11:01 AM
>             *To: *"[email-masked]" <mailto:[email-masked]>
>             <[email-masked]> <mailto:[email-masked]>
>             *Subject: *[EXTERNAL] [regext] Comments to the feedback
>             about epp-over-http
>
>             Hi folks,
>
>             here are in the following some comments grouped by subject
>             to last meeting's feedback about EPP-over-HTTP:
>
>             *1) Draft title*
>
>             SImilarly to RFC5734, the draft states, first in the
>             abstract and then in the security considerations, that TLS
>             is required.
>
>             That being said, the authors don't object to renaming the
>             dcocument EPP-over-HTTPS if the WG agrees.
>
>             *2)  Cookies*
>
>             The reasons why we have used session cookiea are that they
>             represent a standard method (RFC6265), well known to the
>             community of REST service implementers, largely used and
>             natively supported by libraries and frameworks on both
>             client and server side. For example, it is the same method
>             used by rdap-openid to map an RDAP session and tie it to
>             an access token :-)
>
>             .it and .pl have been using this method since the
>             beginning and the registrars, after being informed that
>             they had to enable cookies in their HTTP clients, have no
>             longer complained about cookie management.
>
>             In addition, the implementation of such a method doesn't 
>             introduce any change to the EPP core spec. Indeed, it
>             preserves EPP comands semantics and doesn't mix the
>             application layer with the transport layer.
>
>             I would like to say that, regarding the clear distinction
>             between those layers, this proposal is even better than
>             RFC5734 as every EPP response is returned by the server as
>             a consequence of receiving an EPP request.
>
>             On the contrary, in RFC5734, an EPP <greeting> is returned
>             to the client after the TCP connection has been
>             established so, at least in this case, the**two layers get
>             mixed.
>
>             *3)   Security Considerations*
>
>             Ulirch recommended to review the security considerations
>             by inheriting those from TLS WG about which versions and
>             ciphers of TLS to use.
>
>             Gavin noted that, unlike EPP-over-TCP, this draft states
>             that client IP address check is optional.
>
>             *4)  Cookie vs. HTTP Connection*
>
>             One comment from James in the chat is about establishing
>             the cookie at setup of the connection and not linking it
>             to the EPP Login command.
>
>             James, can you further clarify why we should opt for
>             establishing the cookie at setup of the connection and how
>             shoudl it be possible? For example, what kind of request
>             should be used to start the HTTP connection?
>
>             Programmatically, REST implementers are in charge of
>             processing HTTP requests and building responses rather
>             than managing HTTP connections, which is instead delegated
>             to the application servers.
>
>             Finally, I would like to outline that Section 2.9.1 of
>             RFC5730 states that an EPP session starts with a Login
>             command and the mechanism described by RFC6265 lets (I'm
>             quoting here) "the servers maintain a stateful session
>             over the mostly stateless HTTP protocol". As a
>             consequence, it seems much more practical to start the
>             EPP/HTTP session as a result of a Login command.
>
>             *5) EPP/HTTP Sessions vs. HTTP3 Connections*
>
>             In fact, an HTTP connection can be kept alive and, over
>             it, a client could submit multiple login-commands-logout
>             sequences.
>
>             Instead, It is unlikely but not impossible to come across
>             HTTP connections supporting multiple concurrent sessions.
>
>             *6) Client authentication in HTTP3*
>
>             Another note pointed out that HTTP3 client authentication
>             requirements are different from this draft and they need
>             to be reconciled.
>
>             Think that it could be sufficient to add to the security
>             considerations some text similar to what is included in
>             section 4.4 "Peer authentication" of RFC 9001 "Using TLS
>             to secure QUIC":
>
>                 trusted entity (see for example [RFC2818  <https://secure-web.cisco.com/1tkPqD6aAMfTp6t6KppHDGdn0xpgOWSMeCqwZR-hs9Duph9SiceA0vCbaJJVqywNzcZscc6vUZkCPH9lCdtXq_nVJ3OfnNMz-XTQvhBuSBLsXa0VfO5ZNrGo47fSin8GRaQOWRSvSQP_7vRecBdddhF6L0Yqx3KcxAGpvdxpFCsPhLcd5bm-aVy3vTko6TfGBlohe2XEw3bwUmH-u56ZuZz50CUXUqA3YDFgBENAwPrLBjwdDxwgG1JFVGPZF_LEQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc2818>]).
>
>               
>
>             The draft has only considered the optional use of a
>             certificate on server side (not on client side). In doing
>             that, the draft is consistent with another sentence in the
>             same paragraph of RFC9001:
>
>             Web:http://www.iit.cnr.it/mario.loffredo  <http://secure-web.cisco.com/1Af0lIvD4wj2TkngfEVwrFVEVRozLiVIU2m1Gi1AH1GN4-eWP-IREXsOLCh8OJ03YAxRNYqVCPHQSwgj-tMCyzvN3jokOBTIBx4-5n1pJdiRXxl-ShJCaHkCjGNPa8EA5qw4kPjkxIrFAy1qOTcPFhieqdc_xyu8yisYoXzily9ozVw3GZaUtkKrLnmnDJhlFv2LRTCTnw913LzH8bX-hB6FpPlyFi_0v2_H1NFCgZYjuu4pgUeOeIqQJRQwtzNLS/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
>
>         -- 
>
>         Dr. Mario Loffredo
>
>         Web:http://www.iit.cnr.it/mario.loffredo  <http://secure-web.cisco.com/1OpUT5efcRPCKu9ZmpfyFmbeoIexTqMIlduFKl7VTUSeET1W3oogufCAfJPPw-WSQ0iyo_wkztY_7M69qw0yf13C4w7OWB_Zk5w2FsV-GGCSLot8lFQdslU0DvCpCTw9FjZr0AsFsubGH-kToYrLxzzEj7vGDKuxIFxPK92P5bu2CDOE4UFtRPRGvu9rzX83rks8X2le_j1uSS1SD5B8CyvSp0tsne0HWMS5luho_DIhdOil7-0a_7ZX6CQA08GQq/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
>
>
>
>
>         [email-masked]
>         https://www.ietf.org/mailman/listinfo/regext  <https://secure-web.cisco.com/16jl36WEWq0s-czRNUY5mezogTB1s8eM6-POsf3osvBxTtShse2Gx3vayC92AUxQ8ebDwE9Ob8SzhMcrkTCHnZy_RbpQlkSPKyyG9v1LOvWmmr2bX-q2Kwz-52tKvzlBlfgMU_rKnCsIFS9e53n9Fl1sqideuhzE2Qvq05_MQ6tGzuKP1z0P4vYyDR8QmVl4xwlz-BKFhZLijpQYz9CLe61qg3JAC0a2ldUiZMLUwjnSSssMNXvvVibSRdv-9l9yg/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>
>
>     -- 
>
>     Dr. Mario Loffredo
>
>     Web:http://www.iit.cnr.it/mario.loffredo  <http://secure-web.cisco.com/1yKvefSSzzB1xtPf0Zt9UvXnOkA28n5LvF1HkMnNZqV6Dwz7x7ZD06GbmS94ZAQwsmSA6iszQPAkGi5fNCSMjCHwEbful0vNQc0bfu7a2ydpIkKyqCYgjHlBp7I_-3eCZXAtMTjU_xfTEae9EnXNbksctYNkGyOsHDR02jSoOeVLa3lgW8hWUZ20zgxxFQlt_HdsERDtOQY4EoiE3orLFHDV3wtSA-ChHIYVp1pfMvU2aCEBQ3tWEhFOLp740jUPP/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
>
> -- 
> Dr. Mario Loffredo
> Web:http://www.iit.cnr.it/mario.loffredo  <http://secure-web.cisco.com/1pp2UVbYq0m0PdgNAIf-MFBBPlI6rgwJb-nl0OyxKTaZvJklLUlXEVPn3qvn6ziLbUr86nSYHSn9PLRlT1wKKUgtGjJOdnJ8Ghkk3hlYjxMa4J4AaIOBZ7WvzWPIEvoHPBVb2TdHFIKvtiJkT5ev0nRTy-ErBgM9XRxiNe_p-wkwdeLKKqJWcyzpKSrlr3WZKQaTzmyHAwtIPMymiYesdU2YUhfSeGkOO4qysnLCFQpp6nqMFwr28xmvjE8p7Rz8v/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

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

---

From: Mario Loffredo <[email-masked]>
Date: Thu, 31 Mar 2022 13:52:03 +0200

Hi James,

For what I have understood, your implementation is based on the 
assumption that once the HTTP Connection is established, it is used for 
the transit of all the HTTP requests of an EPP session, starting from 
the Login and ending with the Logout.

Consequently, you rely on keeping the HTTP connection alive as long as 
the EPP session works. Correct?

If so, in my opinion, that is a wrong assumption.

Clients should not be forced to keep alive the HTTP connections if HTTP 
allows to maintain HTTP sessions alive across a sequence of HTTP  
connections.

There are other implications connected with the Keep-Alive Timeout value.

Don't know how did you set the Keep-Alive Timeout: the default value is 
60 secs.

As a consequence, the EPP session timeout value in your implementation 
cannot be higher than the Keep-Alive timeout value, othewise you might 
have the case that an EPP session is still alive but the underlying HTTP 
conection isn't.

Another consequence of binding EPP session to HTTP connections is that, 
when a server is stopped, not only the ongoing EPP requests get lost, 
but also all the corresponding EPP sessions.

Finally, another factor to consider is that there could be some 
intermediaries (proxies) in the middle. Each of them can set their own 
Keep-Alive Timeout you can't control.

On the other hand, following the commonly used approach to make the EPP 
session completely independent on the HTTP conections would contribute 
to make an HTTP-based EPP server more manageable, efficient, flexible 
and fault tollerant.

In my previous mail, I wrote that your implementation seems to me 
impractical because currently no HTTP programmer on both client and 
server side is accostumed to deal directly with HTTP connections because 
that job is done by  the application server (or similar) on top of which 
you deploy (or built) your application based on a high-level protocol 
such as EPP and RDAP. Following this apporach, the implementation of 
EPP-over-HTTP would not be affected by the possible change of the HTTP 
version supported.

Surely, one can tune the performance of the entire server by setting 
some parameters regarding HTTP connections but basically the main job 
consists in processing the requests to return the responses, That's it. 
On client side, you can configure a connection pool instead of 
starting-ending an HTTP connection every time an HTTP request is sent 
but even client libraries allows for creating an HTTP client instance 
and using it to send HTTP requests and process the related responses.

We cannot use HTTP as it was TCP. There are three layers in the middle 
that save HTTP programmers from being involved in low-level details 
(luckily).

With regard to the compliance with RFC5730, the proposed approach 
interprets the specification on the basis that HTTP is neither 
connectionless nor connection-oriented.

It still runs on top of a connection-oriented transport (typically TCP), 
but it does not assign any state to that particular connection. The 
client is free to re-use the same connection for multiple requests (as 
many HTTP/1.1 clients do), or to create a brand new connection for each 
request (as HTTP/1.0 clients used to do).

Best,

Mario

---

From: "Thomas Corte (TANGO support)" <[email-masked]>
Date: Thu, 31 Mar 2022 14:36:34 +0200

Hello Mario,

On 3/31/22 13:52, Mario Loffredo wrote:

> the transit of all the HTTP requests of an EPP session, starting from the 
> Login and ending with the Logout.
> 
> ...

I might be wrong (it was hard to follow the entire discussion, mostly due 
to the lack of consistent e-mail quoting in the thread), but I don't 
think there really any disagreement here between James and you.

As James speaks of HTTP Session Cookies in many places, I don't think 
he's suggesting that the connection management should be required to make 
use of any HTTP keepalive features. Instead, I think that you're both 
agreeing that the EPP "session" over HTTP is simply managed by an initial 
cookie given to the client, which he'll need to send along with any 
subsequent request to indicate that it belong to the same session. This 
also means that, unlike with TCP, an EPP session over HTTP can indeed 
survice a server restart, as long as the server can retrieve sessions 
from permanent storage after its restart.

I think the only point of contention here is when exactly the cookie is 
supposed to be returned by the server, namely

a) at the time the very first request without a session cookie is 
received (i.e., when the EPP client sends a <hello>?) OR
b) only after the first <login> command is received with correct credentials

My preference would be a) as it more closely resembles the TCP transport 
(where the connection itself is established before the first valid <login>).

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES® is a product of:
Knipp Medien und Kommunikation GmbH
Technologiepark                             Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9                       Fax: +49 231 9703-200
D-44227 Dortmund                       E-Mail: [email-masked]
Germany

---

From: Mario Loffredo <[email-masked]>
Date: Thu, 31 Mar 2022 17:36:06 +0200

Hi Thomas,

thanks a lot for your interest as well as your attempt to mediate 
between James's position and mine. Very appreciated :-)

Starting an HTTP session when receiving an EPP command other than the 
Login command is in .it experience (but I can speak on behalf of .pl 
too) very inefficient because you can't immediately lock the HTTP 
session to the Registrar.

It also has some implications on security : to start a session on a 
server, in one case you need only an allowed IP address; in the other, 
you need an allowed IP address, valid credentials and you shouldn't 
exceed the limits of EPP sessions per Registrar.

In addition, while TCP client needs to establish a connection before 
sending the EPP Login command since the transport protocol is 
connection-oriented, an HTTP client doesn't need to do because the 
protocol is not connection-oriented (even if it uses connections). So 
why should an HTTP client be required to send a useless HTTP request? 
Just to operate in the same way of EPP over TCP? It's a nonsense.

With regard to the compliance with RFC5730, the only difference with the 
proposed approach is that a client MAY send an Hello via POST before 
sending a Login. Anyway, the EPP session starts after a successful Login 
as defined in RFC5730 itself.

Is this approach less compliant to RFC5730 than James's one? Maybe. For 
sure it's more efficient (at least both in .it and .pl contexts)

Best,

Mario

Il 31/03/2022 14:36, Thomas Corte (TANGO support) ha scritto:
>> assumption that once the HTTP Connection is established, it is used 
>> for the transit of all the HTTP requests of an EPP session, starting 
>> from the Login and ending with the Logout.
>>
>> Consequently, you rely on keeping the HTTP connection alive as long 
>> as the EPP session works. Correct?
>>
>> Clients should not be forced to keep alive the HTTP connections if 
>> HTTP allows to maintain HTTP sessions alive across a sequence of 
>> HTTP  connections.
>> ...
>
> I might be wrong (it was hard to follow the entire discussion, mostly 
> due to the lack of consistent e-mail quoting in the thread), but I 
> don't think there really any disagreement here between James and you.
>
> he's suggesting that the connection management should be required to 
> make use of any HTTP keepalive features. Instead, I think that you're 
> both agreeing that the EPP "session" over HTTP is simply managed by an 
> initial cookie given to the client, which he'll need to send along 
> with any subsequent request to indicate that it belong to the same 
> session. This also means that, unlike with TCP, an EPP session over 
> HTTP can indeed survice a server restart, as long as the server can 
> retrieve sessions from permanent storage after its restart.
>
> I think the only point of contention here is when exactly the cookie 
> is supposed to be returned by the server, namely
>
> My preference would be a) as it more closely resembles the TCP 
> transport (where the connection itself is established before the first 
> valid <login>).
>
> Best regards,
>
> Thomas
>
Web: http://www.iit.cnr.it/mario.loffredo

---

From: "Patrick Mevzek" <[email-masked]>
Date: Thu, 31 Mar 2022 10:54:19 -0500

> session to the Registrar.

I disagree.

If the transport is HTTPS (and not just HTTP), the server can request
the client to send a certificate, exactly as for EPP over TLS.

In such case, for *any* HTTP request coming to the server, the server
theoretically already knows to which client this pertains as it can
consult the certificate given.

It can be considered a weak or partial authentication, until the EPP login
is successfully executed.

-- 
  Patrick Mevzek
  [email-masked]

---

From: Mario Loffredo <[email-masked]>
Date: Thu, 31 Mar 2022 18:56:02 +0200

Hi Patrick,

thanks for your interest.

> is successfully executed.

Are you talking about a signle server or a load balancing architecture 
where a proxy routes the requents to a pool of backend servers?

In addition, it is quite simple to do at socket level. It seems to me 
much more complicated at the servlet level.

Mario

---

From: "Thomas Corte (TANGO support)" <[email-masked]>
Date: Thu, 31 Mar 2022 19:17:26 +0200

Hello Mario,

On 3/31/22 17:36, Mario Loffredo wrote:

> Login command is in .it experience (but I can speak on behalf of .pl too) 
> very inefficient because you can't immediately lock the HTTP session to 
> the Registrar.

Ok, but plain TCP implementations have the same problem. Unless the 
registry requires that no two registrars have the same IP address 
whitelisted, the server always has to wait for the <login> until it knows 
which registrar has connected. That is, unless client certificates are 
also in play, as suggested by Patrick, but that's not a requirement in 
EPP, even if many registries are now requiring them.

> protocol is not connection-oriented (even if it uses connections). So why 
> should an HTTP client be required to send a useless HTTP request? Just to 
> operate in the same way of EPP over TCP? It's a nonsense.
> 

Obtaining the <greeting> (which, in case of connection-less operation, is 
actually supposed to be triggered by the client's <hello>) before <login> 
isn't useless – the greeting contains information like object/extension 
URIs that can be used by the client to select a proper supported 
object/extension implementation before sending the <login> (in which that 
support is declared). So, for HTTP, it makes sense to require the 
client's <hello> so that the server's <greeting> can be sent as the 
response to a proper initial request (rather than, say, an awkward empty 
POST, or a GET request).

In fact, it memory serves, ITNIC's *current* EPP-over-HTTP implementation 
*requires* a <hello> as the start of any EPP session.

Best regards,

Thomas

---

From: Francisco Obispo <[email-masked]>
Date: Thu, 31 Mar 2022 10:36:34 -0700

In a scenario where a proxy/load balancer is terminating the TLS 
connection, it will most likely need to extract the certificate 
information, and encode it into a HTTP header, so that the backend could 
later tie the `clID` with the certificate in a way (i.e.: `cn`).

That's what I would do, to at least guarantee that the client 
certificate correspond to the `clID`.

Best,

---

From: Mario Loffredo <[email-masked]>
Date: Thu, 31 Mar 2022 19:44:02 +0200

Hi Thomas,

Il 31/03/2022 19:17, Thomas Corte (TANGO support) ha scritto:
> whitelisted, the server always has to wait for the <login> until it 
> knows which registrar has connected. That is, unless client 
> certificates are also in play, as suggested by Patrick, but that's not 
> a requirement in EPP, even if many registries are now requiring them.
>
>> With regard to the compliance with RFC5730, the only difference with 
>> the proposed approach is that a client MAY send an Hello via POST 
>> before sending a Login. Anyway, the EPP session starts after a 
>> successful Login as defined in RFC5730 itself.
>
> Obtaining the <greeting> (which, in case of connection-less operation, 
> is actually supposed to be triggered by the client's <hello>) before 
> <login> isn't useless – the greeting contains information like 
> object/extension URIs that can be used by the client to select a 
> proper supported object/extension implementation before sending the 
> <login> (in which that support is declared). So, for HTTP, it makes 
> sense to require the client's <hello> so that the server's <greeting> 
> can be sent as the response to a proper initial request (rather than, 
> say, an awkward empty POST, or a GET request).

The point is that sending an hello before a Login is optional. If you 
are already perfectly aware of the services provided by the server, why 
should you submit an Hello to discover them?

>
> In fact, it memory serves, ITNIC's *current* EPP-over-HTTP 
> implementation *requires* a <hello> as the start of any EPP session.

Not at all.

For sure, .it implementation have never required to send an Hello before 
a Login. EPP sessions have always been started after a Login.

Trust me ;-)

Mario

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 31 Mar 2022 17:58:20 +0000

> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of Thomas Corte
> (TANGO support)
> Sent: Thursday, March 31, 2022 1:17 PM
> To: [email-masked]
> 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.
> 
> Hello Mario,
> 
> registry requires that no two registrars have the same IP address whitelisted,
> the server always has to wait for the <login> until it knows which registrar has
> connected. That is, unless client certificates are also in play, as suggested by
> Patrick, but that's not a requirement in EPP, even if many registries are now
> requiring them.

[SAH] Client certificates ARE required for TCP transport with TLS. See here:

https://datatracker.ietf.org/doc/html/rfc5734#section-9

They're not specifically a requirement for EPP, but they are for that particular transport protocol (which just happens to be the only standard transport protocol).

Scott

---

From: Mario Loffredo <[email-masked]>
Date: Thu, 31 Mar 2022 20:14:33 +0200

Hi Francisco,

Maybe we are complicating a bit (just to be polite) something that 
would  be very easy if the server started every EPP session only after a 
successful Login.

Anyway, just for curiosity, can you provide me with an example for NGINX?

It doesn't sound so simple according to this post 
<https://stackoverflow.com/questions/64810700/reading-client-certificate-details-with-nginx>

Best,

Mario

Il 31/03/2022 19:36, Francisco Obispo ha scritto:
> information, and encode it into a HTTP header, so that the backend 
> could later tie the |clID| with the certificate in a way (i.e.: |cn|).
>
> certificate correspond to the |clID|.
>
> Best,
>
>     Are you talking about a signle server or a load balancing
>     architecture where a proxy routes the requents to a pool of
>     backend servers?
>
>     In addition, it is quite simple to do at socket level. It seems to
>     me much more complicated at the servlet level.
>
>     Mario
>
>     -- 
>     Dr. Mario Loffredo

---

From: Francisco Obispo <[email-masked]>
Date: Thu, 31 Mar 2022 11:21:15 -0700

Something like this would work with HAproxy:

https://www.haproxy.com/blog/ssl-client-certificate-information-in-http-headers-and-logs/

Best,

On 31 Mar 2022, at 11:14, Mario Loffredo wrote:

> would  be very easy if the server started every EPP session only 
> after a successful Login.
>
>>         In such case, for *any* HTTP request coming to the server, 
>> the
>>         server

---

From: Mario Loffredo <[email-masked]>
Date: Thu, 31 Mar 2022 22:03:20 +0200

Hi Francisco,

appreciated but:

1) The ssl variables in NGINX are different.

2) Even supposing to extract CN or SAN, as it seems one should do in 
NGINX via a regular expression, it doesn't necessarily correspond to the 
registrar username to access the EPP server.

3) I repeat: why should I complicate a solution to come to another that 
I consider less efficient?

Thanks again for the example that maybe will be useful in the future :-)

Best,

Mario

Il 31/03/2022 20:21, Francisco Obispo ha scritto:
>>     information, and encode it into a HTTP header, so that the
>>     backend could later tie the |clID| with the certificate in a way
>>     (i.e.: |cn|).
>>
>>         In addition, it is quite simple to do at socket level. It
>>         seems to me much more complicated at the servlet level.
>>
>>         Mario
>>
>>         --
>>         Dr. Mario Loffredo

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 31 Mar 2022 20:11:01 +0000

From: regext <[email-masked]> On Behalf Of Mario Loffredo
Sent: Thursday, March 31, 2022 4:03 PM
To: Francisco Obispo <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [regext] Comments to the feedback about epp-over-http

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 Francisco,

appreciated but:

2) Even supposing to extract CN or SAN, as it seems one should do in NGINX via a regular expression, it doesn't necessarily correspond to the registrar username to access the EPP server.

3) I repeat: why should I complicate a solution to come to another that I consider less efficient?

[SAH] For ease of interoperability with clients (registrars) who have to work with other servers (registries) that follow the specifications more closely.

Scott

---

From: Francisco Obispo <[email-masked]>
Date: Thu, 31 Mar 2022 13:19:04 -0700

Hi Mario,

Response inline.

> 1) The ssl variables in NGINX are different.

Yes, they usually are :-)

> NGINX via a regular expression, it doesn't necessarily correspond to 
> the registrar username to access the EPP server.

Well, whichever method is used, it is important to tie the SSL client to 
the `clID` otherwise an authorized client could try to login with a 
separate account, so it serves the purpose of a multi-factor 
authentication:

* IP address whitelist
* SSL client certificate pinning
* clID/password combination

> that I consider less efficient?

Those methods described above, happen at different layers in the stack, 
it is not complicated, this is exactly how we operate today (at least 
Tucows Registry), SSL certificates are checked to ensure they belong to 
the clID.

IMO a new transport for EPP should at least offer the same safeguards.

> Thanks again for the example that maybe will be useful in the future 

N/P, this is very similar to how IP access works at the HTTP level using 
the `X-Forwarded-For` header or similar approach to signal the 
application information about the client.

Francisco