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

From: "Gould, James" <[email-masked]>
Date: Tue, 29 Mar 2022 11:41:30 +0000

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://verisigninc.com/>

From: Mario Loffredo <[email-masked]>
Date: Monday, March 28, 2022 at 6:59 AM
To: James Gould <[email-masked]>, "[email-masked]" <[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)

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.
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>

---

From: Mario Loffredo <[email-masked]>
Date: Tue, 29 Mar 2022 16:58:09 +0200

Hi James,

Il 29/03/2022 13:41, 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: *Monday, March 28, 2022 at 6:59 AM
> *To: *James Gould <[email-masked]>, "[email-masked]" 
> <[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.
>
>     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:
>
>  5. Support HTTP requests in the form of framed EPP commands that are
>     returned in HTTP responses in the form of framed EPP responses.
[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.

> 1.
>
>
> 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.

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,
>
>     *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.
>
>     *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>
>
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

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

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 30 Mar 2022 09:02:08 +0200

Guys,

i’ve yet to read up on the latest version of the document (and I will do so). However, as a quick comment:

[AM] Please please let’s not assume that HTTP is TCP. The protocol (imho MUST) also work over HTTP/3, which uses QUIC, which in turn uses UDP. However, the approach of using a session ID for identifying the equivalent of a TCP connection in “plain” EPP is still valid, and I support that design choice.

More feedback to come once I manage to squeeze in time to read through the draft more carefully.

Best,

Alex