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

From: "Gould, James" <[email-masked]>
Date: Fri, 25 Mar 2022 15:45:43 +0000

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

--

JG

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

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

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

From: regext <[email-masked]> on behalf of Mario Loffredo <[email-masked]>
Date: Friday, March 25, 2022 at 11:01 AM
To: "[email-masked]" <[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>

---

From: Mario Loffredo <[email-masked]>
Date: Mon, 28 Mar 2022 12:56:57 +0200

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?

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://www.rfc-editor.org/rfc/rfc7230#section-3>) across a reliable transport- or
    session-layer "connection" (Section 6  <https://www.rfc-editor.org/rfc/rfc7230#section-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.*

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.

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

Best,

Mario

> -- 
>
> JG
>
>
>
>
> *James Gould
> *Fellow Engineer
> [email-masked] 
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
> *From: *regext <[email-masked]> on behalf of Mario Loffredo 
> <[email-masked]>
> *Date: *Friday, March 25, 2022 at 11:01 AM
> *To: *"[email-masked]" <[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.
>
> *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>

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

---

From: Matthias Pfeifer <[email-masked]>
Date: Mon, 28 Mar 2022 23:40:34 +0200

Hello,

i would also add a comment and questions:

 >In the perspective of moving to the cloud to achieve scalability and
 >  cost reduction, it should be further noted that application protocols
 >   that aren't based on HTTP can be hardly migrated by using cloud-
 >   native features, both on client side and server side.  In addition,
 >   from the security point of view, registries would be limited in terms
 >   of the third-party security services available to protect their EPP
 >   servers.

Can you please elaborate on

 >"registries would be limited in terms of the third-party security 
services available to protect their EPP >servers."

Why?

And also on

 >"and should be further noted that application protocols
 >that aren't based on HTTP can be hardly migrated by using cloud-
 >native features, both on client side and server side. " (since the 
cloudproviders offer tcp LB as well)

 >While TCP is connection-oriented, HTTP is stateless but not session
 >less.  This means that, by making an EPP session untied from the
 >network connection, the EPP communication over HTTP is more flexible
 >and efficient than over TCP.

They work on different Layers so IMHO its hard to make a comparsion in 
that way.

 >While HTTP load balancers are very common and are quite often 
software, TCP load
 > balancers are usually implemented in dedicated hardware

Whats the point? TCP and HTTP LBs are even used in combination

 >An EPP server made up of a server pool must always operate with
 >respect to the constraint that, once an EPP session is established,
 >all the requests related to that session should be processed by the
 >servers in the pool as long as the session is alive.

This is true in general and there are workarounds (eg CARP or VRRP  and 
token)
The LB part looks too one-sided to me

 >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 :-)

 > Which method other than session cookie shoud be used instead ?

For (REST) API I would prefer token(JWT) based model in general. Login / 
Logout including session management would add (at least a little bit) 
more complexity and probably CORS issues on client side.

Why we don't chase the transport protocol restriction out of EPP in 
general? :)

Thx and best, Matthias

---

From: Mario Loffredo <[email-masked]>
Date: Tue, 29 Mar 2022 11:26:05 +0200

Hi Matthias,

thanks a lot for your interest and feedback.

Please find my comments inline prefixed with [ML]

> cloudproviders offer tcp LB as well)
[ML] I added the text above following up the feedback provided by Gavin 
from CentralNIC who probably has already experienced some drawbacks in 
migrating to cloud his EPP server based on TCP.

@Gavin, you are surely more knowledgeable than me about this topic so if 
you wish to integrate my response, please feel free to do it.

My knowledge is limited to what I have learnt from the web.

That said, AFAIK most of cloud providers don't allow to open low level 
sockets. You cannot use any port except 80 and 443 (HTTP and HTTPS).  I 
imagine that they do that due to security reasons.

Honestly don't know whether and how such a block can be bypassed.

In addition, from what I've read, TCP load balancers are intended for 
TCP traffic on well-known ports, such as port 25 for SMTP.

It seems quite clear to me that cloud platforms have been designed to 
natively support HTTP-based rather than TCP-based applications.

> They work on different Layers so IMHO its hard to make a comparsion in 

[ML] We can compare their effects on the functioning of an EPP server.

SInce in EPP-over-TCP, an EPP session is mapped on a TCP connection, the 
session gets lost if the TCP connection breaks down.

This doesn't happen in EPP-over-HTTP because the EPP session is mapped 
on an HTTP session that is a pure logical concept.

In addition, if the EPP session is maintained outside the EPP server (or 
a pool of backend servers in a load balancing scheme) , the EPP session 
doesn't get lost even when the server (or one of the servers that has 
previously started the EPP session) is stopped.

> Whats the point? TCP and HTTP LBs are even used in combination

[ML] The point is that HTTP load balancers are more flexible than TCP 
load balancers because they work at a higher layer.

Let's suppose, for example, to have an HTTP server based on HTTP/2 and 
we want to move to QUIC.

I presume that such a change would require little to no effort on the 
HTTP load balancer.

> This is true in general and there are workarounds (eg CARP or VRRP  
> and token)

[ML] Sorry, can you further clarify your remark?

I confess that I don't know CARP and VRRP in detail but it seems to me 
that they can't be helpful to figure out how to store session 
information to make session survive server failures.

In the case where sticky sessions are used and each backend server 
maintains the HTTP sessions it starts, if a server breaks down, you can 
recover the server but not its sessions.

Whereas sessions are stored on a persistent memory outside the backend 
servers and any server is able to serve the EPP requests, you can 
redirect the EPP traffic to another server without any impact on client 
side.

Anyway, we'll further review that section to make it appear more objective.

>
> And a comment:
>
> >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 :-)
>
> For (REST) API I would prefer token(JWT) based model in general. Login 
> / Logout including session management would add (at least a little 
> bit) more complexity and probably CORS issues on client side.

[ML] I would agree with you if the goal was to partially or completely 
refactor EPP but this is not the philosophy behind this proposal.

This proposal aims to preserve EPP commands semantics and makes use of 
HTTP as a mere transport protocol.

So what are the other practical methods using HTTP that way and 
preserving the EPP commands?

James proposed his own one but the authors'opinion is that it involves a 
very low-level approach.

Except for setting the session cookie, this proposal doesn't require to 
know any additional features used in the REST context.

Therefore, I think it would be quite easy to wrap the core of an EPP 
server to make it interact with both a TCP and an HTTP server.

With regard to the use of a JWT token, while reviewing the rdap-openid 
document the WG has already agreed that it is unfit to be used outside 
the borders of a trusted environment. As a consequence, Scott

has recently replaced tokens with sessions (the same mechanism used by 
epp-over-http) in the interaction between a generic RDAP client and an 
RDAP server and stated tokens to be exchanged between the RDAP server, 
acting as registered OpenID Connect client, and an OpenID Provider.

It should further be noted that not only the Login command lets the 
client authenticate but also negotiate the XML namespaces that will be 
valid during the EPP session. Therefore, the simple replacement of the 
EPP authentication with another HTTP-based mechanism wouldn't be 
sufficient.

> Why we don't chase the transport protocol restriction out of EPP in 

[ML] Are you proposing to rewrite EPP :-) ?

I don't object to the idea but, IMHO, a general refactoring of EPP 
should also address other topics; for example, the use of JSON instead 
of XML so that extensions can be managed more easily.

Hope I addresed all your remarks.

Best,

Mario

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

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