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

From: Mario Loffredo <[email-masked]>
Date: Fri, 25 Mar 2022 15:58:35 +0100

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://datatracker.ietf.org/doc/html/rfc2818>]).

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

---

From: "Thomas Corte (TANGO support)" <[email-masked]>
Date: Tue, 29 Mar 2022 14:05:40 +0200

Hello,

On 3/25/22 15:58, Mario Loffredo wrote:

> ...
> ...

In terms of EPP-over-HTTP implementations in the wild, RED.ES's abysmal 
implementation for .es comes to mind, which uses a proprietary EPP 
extension for the submission of the EPP client's credentials along with 
each and every command. But such a move away from a stateful EPP session 
is surely not desirable, leaving cookies (or some other way to maintain 
state over multiple HTTP requests) as the only sensible choice.

Best regards,

Thomas Corte

-- 
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: Tue, 29 Mar 2022 17:07:37 +0200

Hi Thomas,

Il 29/03/2022 14:05, Thomas Corte (TANGO support) ha scritto:
> In terms of EPP-over-HTTP implementations in the wild, RED.ES's 
> abysmal implementation for .es comes to mind, which uses a proprietary 
> EPP extension for the submission of the EPP client's credentials along 
> with each and every command. But such a move away from a stateful EPP 
> session is surely not desirable, leaving cookies (or some other way to 
> maintain state over multiple HTTP requests) as the only sensible choice.

That's exactly my main concern about such an idea that was the same 
supporting last proposal about EPP-over-HTTP submitted to this WG.

Making EPP completely stateful appeared,and still apeears, to me 
inefficient and in contrast with the trend in the design of REST services.

Best,

Mario

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

---

From: "Thomas Corte (TANGO support)" <[email-masked]>
Date: Tue, 29 Mar 2022 17:29:42 +0200

Hello Mario,

> inefficient and in contrast with the trend in the design of REST services.

EPP *is* stateful by definition (see "Protocol Description" in RFC 5730), 
and that has implications beyond the fact that credentials are only 
presented to the server in the <login>. The <login> also contains 
"handshake" information that tells the server which object and extension 
URIs the client understands, and that information governs the content of 
server responses during the session (e.g., which version of fee extension 
data is returned in the response to a billable operation).

Consequently, EPP would need to be completely revamped in order to 
facilitate stateless operation. All extensions relying on the <login> 
handshake would need to be rewritten. The use of cookies (a 
well-established method to maintain server state over HTTP) seems like 
the lesser evil here.

Best regards,

Thomas