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

[Mario Loffredo]

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


Il 30/03/2022 15:59, Gould, James ha scritto:


Mario,

I include my feedback embedded below.

--

JG




*James Gould
*Fellow Engineer
jgo...@verisign.com 



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

Verisign.com 

*From: *Mario Loffredo 
*Date: *Wednesday, March 30, 2022 at 8:28 AM
*To: *James Gould , "regext@ietf.org" 

*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
jgo...@verisign.com


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

Verisign.com



*From: *Mario Loffredo 

*Date: *Tuesday, March 29, 2022 at 11:00 AM
*To: *James Gould 
, "regext@ietf.org"
  
*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
jgo...@verisign.com



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

Verisig

Re: [regext] WG LAST CALL: draft-ietf-regext-epp-eai-04

[Jody Kolker]

All,

My apologies for the lateness of this reply.

As the Document shepherd I have verified that no substantial changes were made 
since version 04 of the document.  I will start my writeup of the document and 
plan to complete in the next several days.

Please let me know if you have any questions.

Thanks,
Jody Kolker.

From: regext  On Behalf Of Antoin Verschuren
Sent: Thursday, December 23, 2021 3:59 PM
To: regext@ietf.org
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-epp-eai-04

Caution: This email is from an external sender. Please do not click links or 
open attachments unless you recognize the sender and know the content is safe. 
Forward suspicious emails to isitbad@.


And with this, this WGLC is now formally closed.
The chairs count enough support for this draft (+6 not counting document 
authors and shepherds) to be able to declare consensus.

However, this draft changed from version 04 to version 06 during WGLC, and we 
need a confirmation from the document shepherd in his review that only 
editorial and no substantive changes were made, and all concerns during WGLC 
are addressed in version 06.
Protocol dictates us that when substantive changes were made to a document 
during WGLC, we need to issue a second WGLC before we can declare consensus and 
submit it to the IESG.

The document shepherd for this document is Jody Kolker.
Jody, when you have done your review, please let us know the result.
When there were no substantive changes during WGLC, you can start the shepherd 
writeup for version 06.

Regards,

Jim and Antoin





Op 23 dec. 2021, om 12:05 heeft Dmitry Belyavsky 
mailto:beld...@gmail.com>> het volgende geschreven:

Dear Scott,

Many thanks for your nitpicking!
I've addressed your concern about Section 6 using your words, many thanks!

As for the namespace version, as James wrote before, we are going to update it 
after the WGLC.

Merry Christmas and Happy New Year!

On Tue, Dec 21, 2021 at 5:15 PM Hollenbeck, Scott 
mailto:40verisign@dmarc.ietf.org>>
 wrote:

From: regext mailto:regext-boun...@ietf.org>> On 
Behalf Of Antoin Verschuren
Sent: Monday, December 20, 2021 8:55 AM
To: regext@ietf.org
Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-epp-eai-04

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.
Dear WG,

This WGLC will end tonight, and so far we only have 2 explicit voices of 
support.
This is a bit low to declare consensus. Could more people voice their support?
Scott, can you confirm that the changes in version 05 address your initial 
concerns?
[SAH] Not yet fixed completely:

Section 6 still doesn't explain why "Registries SHOULD validate the domain 
names syntax in the provided email addresses". I suggested this text in an 
earlier note:

"Registries SHOULD ensure that the provided email addresses are syntactically 
valid to reduce the risk of future usability errors."

The IANA Considerations section still uses "eai-0.3". It should be "eai-1.0".

Scott
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


--
SY, Dmitry Belyavsky
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Fwd: New Version Notification for draft-ietf-regext-epp-eai-07.txt

[Jody Kolker]

Thank you Dmitry.

@Jim (Gould) and Dimtry - Does this draft contain any IPR?  We'll need to know 
in order to complete the review for the submission.

Thanks,
Jody Kolker.


-Original Message-
From: regext  On Behalf Of Dmitry Belyavsky
Sent: Friday, January 21, 2022 12:15 PM
To: regext 
Subject: [regext] Fwd: New Version Notification for 
draft-ietf-regext-epp-eai-07.txt

Caution: This email is from an external sender. Please do not click links or 
open attachments unless you recognize the sender and know the content is safe. 
Forward suspicious emails to isitbad@.



Dear colleagues,

The new version of draft-ietf-regext-epp-eai-07.txt is uploaded.
We increased the namespace version to 1.0 covering the last issue we had with 
this draft.

-- Forwarded message -
From: 
Date: Fri, Jan 21, 2022 at 7:12 PM
Subject: New Version Notification for draft-ietf-regext-epp-eai-07.txt
To: Dmitry Belyavskiy , James Gould 



A new version of I-D, draft-ietf-regext-epp-eai-07.txt has been successfully 
submitted by Dmitry Belyavskiy and posted to the IETF repository.

Name:   draft-ietf-regext-epp-eai
Revision:   07
Title:  Use of Internationalized Email Addresses in the
Extensible Provisioning Protocol (EPP)
Document date:  2022-01-21
Group:  regext
Pages:  11
URL:
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-regext-epp-eai-07.txt&data=04%7C01%7Cjkolker%40godaddy.com%7Ce8bffe3ad2d0438a8aaf08d9dd09f191%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637783857060831055%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=pfTFTaVWTsnXKTaieCENLSJ9sDFNT2osbgiDCY7DbVs%3D&reserved=0
Status: 
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-epp-eai%2F&data=04%7C01%7Cjkolker%40godaddy.com%7Ce8bffe3ad2d0438a8aaf08d9dd09f191%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637783857060831055%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FcZw9h5xzIhtFofQFP5vtPKfnyIlg8z4U1wE27SYh4A%3D&reserved=0
Html:
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-regext-epp-eai-07.html&data=04%7C01%7Cjkolker%40godaddy.com%7Ce8bffe3ad2d0438a8aaf08d9dd09f191%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637783857060831055%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=JH0RGF3ZpW6pVrKna5ThGvdJrr%2Be7MpEWT%2FDb%2B4fWW0%3D&reserved=0
Htmlized:   
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-epp-eai&data=04%7C01%7Cjkolker%40godaddy.com%7Ce8bffe3ad2d0438a8aaf08d9dd09f191%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637783857060831055%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=YCoxywYto9GyF9JZE82ilbNLmo%2BdsHU1XbDLdgtimqQ%3D&reserved=0
Diff:   
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-regext-epp-eai-07&data=04%7C01%7Cjkolker%40godaddy.com%7Ce8bffe3ad2d0438a8aaf08d9dd09f191%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637783857060831055%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6wAeoQOkNvgPS9iGYFaf4VVH7TwaKhBDA%2FQ89SYDh4k%3D&reserved=0

Abstract:
   This document describes an EPP extension that permits usage of
   Internationalized Email Addresses in the EPP protocol and specifies
   the terms when it can be used by EPP clients and servers.  The
   Extensible Provisioning Protocol (EPP), being developed before
   appearing the standards for Internationalized Email Addresses (EAI),
   does not support such email addresses.

   TO BE REMOVED on turning to RFC: The document is edited in the
   dedicated github repo 
(https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbeldmit%2Feppeai&data=04%7C01%7Cjkolker%40godaddy.com%7Ce8bffe3ad2d0438a8aaf08d9dd09f191%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637783857060831055%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2B3XHUJQMJAJ431jeEn9i0MIs93nneIDAowVLGcCbrCI%3D&reserved=0).
  Please
   send your submissions via GitHub.




The IETF Secretariat




--
SY, Dmitry Belyavsky

___
regext mailing list
regext@ietf.org
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext&data=04%7C01%7Cjkolker%40godaddy.com%7Ce8bffe3ad2d0438a8aaf08d9dd09f191%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637783857060831055%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=K2QeUYYuX83nU6pA1L%2FdMLTRy1SOFZiOpy

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

[Thomas Corte (TANGO support)]

Hello Mario,

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


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.

...


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 ?) OR

b) only after the first  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 ).


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: supp...@tango-rs.com
Germany

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Mario Loffredo]

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:

Hello Mario,

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


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.

...


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 ?) OR
b) only after the first  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 ).


Best regards,

Thomas


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

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Patrick Mevzek]

On Thu, Mar 31, 2022, at 10:36, Mario Loffredo wrote:
> 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.

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
  p...@dotandco.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Mario Loffredo]

Hi Patrick,

thanks for your interest.

Il 31/03/2022 17:54, Patrick Mevzek ha scritto:

On Thu, Mar 31, 2022, at 10:36, Mario Loffredo wrote:

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.

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.


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

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Thomas Corte (TANGO support)]

Hello Mario,

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

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.


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


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.


Obtaining the  (which, in case of connection-less operation, is 
actually supposed to be triggered by the client's ) before  
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  (in which that 
support is declared). So, for HTTP, it makes sense to require the 
client's  so that the server's  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  as the start of any EPP session.


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: supp...@tango-rs.com
Germany

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Francisco Obispo]

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,


On 31 Mar 2022, at 9:56, Mario Loffredo wrote:


Hi Patrick,

thanks for your interest.

Il 31/03/2022 17:54, Patrick Mevzek ha scritto:

On Thu, Mar 31, 2022, at 10:36, Mario Loffredo wrote:
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.

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.


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

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Mario Loffredo]

Hi Thomas,

Il 31/03/2022 19:17, Thomas Corte (TANGO support) ha scritto:

Hello Mario,

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

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.


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


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.


Obtaining the  (which, in case of connection-less operation, 
is actually supposed to be triggered by the client's ) before 
 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 
 (in which that support is declared). So, for HTTP, it makes 
sense to require the client's  so that the server's  
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  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



Best regards,

Thomas


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

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Hollenbeck, Scott]

> -Original Message-
> From: regext  On Behalf Of Thomas Corte
> (TANGO support)
> Sent: Thursday, March 31, 2022 1:17 PM
> To: regext@ietf.org
> 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.
> 
> Hello Mario,
> 
> On 3/31/22 17:36, Mario Loffredo wrote:
> 
> > 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.
> 
> 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  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
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Mario Loffredo]

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 



Best,

Mario


Il 31/03/2022 19:36, Francisco Obispo ha scritto:


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,

On 31 Mar 2022, at 9:56, Mario Loffredo wrote:

Hi Patrick,

thanks for your interest.

Il 31/03/2022 17:54, Patrick Mevzek ha scritto:

On Thu, Mar 31, 2022, at 10:36, Mario Loffredo wrote:

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.

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.

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

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

___
regext mailing list
regext@ietf.org

https://www.ietf.org/mailman/listinfo/regext


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


--
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
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Francisco Obispo]

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:


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 



Best,

Mario


Il 31/03/2022 19:36, Francisco Obispo ha scritto:


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,

On 31 Mar 2022, at 9:56, Mario Loffredo wrote:

Hi Patrick,

thanks for your interest.

Il 31/03/2022 17:54, Patrick Mevzek ha scritto:

On Thu, Mar 31, 2022, at 10:36, Mario Loffredo wrote:

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.

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.

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

___
regext mailing list
regext@ietf.org

 https://www.ietf.org/mailman/listinfo/regext


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


--
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
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Mario Loffredo]

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:


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:

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



Best,

Mario


Il 31/03/2022 19:36, Francisco Obispo ha scritto:


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,

On 31 Mar 2022, at 9:56, Mario Loffredo wrote:

Hi Patrick,

thanks for your interest.

Il 31/03/2022 17:54, Patrick Mevzek ha scritto:

On Thu, Mar 31, 2022, at 10:36, Mario Loffredo wrote:

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.

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.

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

___
regext mailing list
regext@ietf.org

https://www.ietf.org/mailman/listinfo/regext


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


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


--
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
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Hollenbeck, Scott]

From: regext  On Behalf Of Mario Loffredo
Sent: Thursday, March 31, 2022 4:03 PM
To: Francisco Obispo 
Cc: regext@ietf.org
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:

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?

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

Scott
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Francisco Obispo]

Hi Mario,

Response inline.

On 31 Mar 2022, at 13:03, Mario Loffredo wrote:


Hi Francisco,

appreciated but:

1) The ssl variables in NGINX are different.



Yes, they usually are :-)



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.


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

3) I repeat: why should I complicate a solution to come to another 
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___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] STD 95, RFC 9224 on Finding the Authoritative Registration Data Access Protocol (RDAP) Service

[rfc-editor]

A new Request for Comments is now available in online RFC libraries.

STD 95
RFC 9224

Title:  Finding the Authoritative Registration Data 
Access Protocol (RDAP) Service 
Author: M. Blanchet
Status: Standards Track
Stream: IETF
Date:   March 2022
Mailbox:marc.blanc...@viagenie.ca
Pages:  15
Obsoletes:  RFC 7484
See Also:   STD 95

I-D Tag:draft-ietf-regext-rfc7484bis-06.txt

URL:https://www.rfc-editor.org/info/rfc9224

DOI:10.17487/RFC9224

This document specifies a method to find which Registration Data
Access Protocol (RDAP) server is authoritative to answer queries for
a requested scope, such as domain names, IP addresses, or Autonomous
System numbers. This document obsoletes RFC 7484.

This document is a product of the Registration Protocols Extensions Working 
Group of the IETF.

This is now an Internet Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext