Mario, allow me to make a minor adjustment to my suggestion:
“Servers MUST implement at least one method of access control that limits server connection access to only authorized clients. Implementation of multiple access control methods is RECOMMENDED.” We need to be clear that unauthorized clients should NOT be allowed to send ANYTHING to a server that might get processed as part of an EPP interaction. Scott From: regext <regext-boun...@ietf.org> On Behalf Of Mario Loffredo Sent: Thursday, February 22, 2024 9:30 AM To: Hollenbeck, Scott <shollenbeck=40verisign....@dmarc.ietf.org>; regext@ietf.org Subject: [EXTERNAL] Re: [regext] Fwd: New Version Notification for draft-loffredo-regext-epp-over-http-03.txt 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 Scott, Il 22/02/2024 13:54, Hollenbeck, Scott ha scritto: I understand that there are options available for client authentication, and that this isn’t necessarily easy for clients. However, there are known attacks that can be perpetrated against servers that allow TCP or TLS connections from unauthorized clients. One example is described here: https://hackcompute.com/hacking-epp-servers/<https://secure-web.cisco.com/1ue8wHGIlyxN-IrXsOyzbTYD2z-ImIVuVvGbKx2t8qM3_V_9oPO2stGT8UYOaw49CYpBUhOaoiyd39bmY4CzNUClJixr7ufI3bKnxp_ociah6fFteJluIGb4rWt7wzCHlOsXKuThrqfwmuQKmJ-uaH2YphL5uivdiSfE1M8WROt3QoulHSHuBbNLLeHnXrF6bODtiboQVTmt2jW4C7YnmY2uHo2B93UgH73WgICFH7tWclRkLp6H3jfdX1hRw7kLsxE3DTl-AIx2d_W83y9Gk-IhrvuLJxh3OlyX3mH0FZWk/https%3A%2F%2Fhackcompute.com%2Fhacking-epp-servers%2F> [ML] I will look into this. If there’s something about client certificates that makes them impossible to use, fine, replace them with another required mechanism. As such, the draft should say something like this: Servers MUST implement at least one method of access control that limits server access to only authorized clients. Implementation of multiple access control methods is RECOMMENDED. [ML] Sounds reasonable to me. I'll incorporate this change into the next version. Thanks a lot for your feedback. Best, Mario Scott From: Mario Loffredo <mario.loffredo=40iit.cnr...@dmarc.ietf.org><mailto:mario.loffredo=40iit.cnr...@dmarc.ietf.org> Sent: Thursday, February 22, 2024 1:52 AM To: Hollenbeck, Scott <shollenb...@verisign.com><mailto:shollenb...@verisign.com>; regext@ietf.org<mailto:regext@ietf.org> Subject: [EXTERNAL] Re: [regext] Fwd: New Version Notification for draft-loffredo-regext-epp-over-http-03.txt 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 Scott, thanks for your quick reply. Please find my comment below. Il 21/02/2024 13:47, Hollenbeck, Scott ha scritto: Tanks for posting the draft, Mario. One quick question: RFC 5734 (Extensible Provisioning Protocol (EPP) Transport over TCP) states that “Mutual client and server authentication using the TLS Handshake Protocol is REQUIRED”. Section 8 of the draft weakens this requirement, stating that “servers SHOULD require clients to present a digital certificate”. HTTPS requires both TCP and TLS, so why weaken the requirement? [ML] There are technical (1-2), ethical (3) and practical (4) reasons. With regard to reasons 3-4, I can speak on behalf of .it but I'm pretty sure the situation is quite the same in other ccTLDs. 1) In TLS (RFC 5246), servers must provide clients with a certificate but clients may provide servers with a certificate if it is requested by servers. It all depends on the application protocol built on top of HTTPS. If the purpose of requiring clients to issue a certificate is implementing a kind of 2FA to enforce EPP client authentication in addition to client's credentials, that is not the only way to go. For example, .it requires that a client ip address could be used by one only registrar where a registrar can use multiple client ip addresses. The association between them is created out-of-band, stored in the underlying db and recorded in the HTTP session, once it is started . Therefore, at any request, the server (i.e. one of the backend server cited below) is able to verify that noone is trying to impersonate someone else. Definitvely, I wouldn't say that using SHOULD instead of MUST weakens the requirement of enforcing client authentication as long as alternative measures could be as secure as client certificates. 2) In an L7 load balancer (LB), clients issue the requests over HTTPS and the LB forwards the requests to the backend servers (BSs) over HTTP. This is to speed up the communication between the LB and the BSs. There is no need to set up an SSL channel between them because the LB is normally exposed on the border of a protected network while the BSs are inside that network. A firewall filters the access by allowing only the communication on port 443 and only from a selected list of ip addresses. The LB logic for routing the incoming requests is very simple, hence you can easily forward a client ip address but it would be much harder to extract the client identity from a certificate (i.e. either CN or SAN) and forward it through an ad-hoc HTTP request header field to let the BS verifies the client identity. 3) Most of .it registrars (~ 1100) are italian SMEs managing only .it domains. When, in 2009, .it migrated from the old registration system, based on issuing fax, to the new one, based on issuing EPP commands over HTTP, the mission of that transition was to reduce as much as possible the technological effort required to registrars to comply with the new rules and avoid to discriminate small players who could not be as technologically powerful as the big ones. To make that transition as smooth as possible, we provided some measures to support them in everything. At that time, we evaluated client certificates could appear a practice increasing that technological divide. Then we opted for other fairer and as effective practices. 4) .it domain names market is very dynamic. Companies merge and, as a result of changing the company names, new registrars are registered with new credentials and new client certificate would be needed. Client IP addresses looks more stable. For sure, updating the set of allowed IP addresses per registrar doesn't cost a thing. I'm aware that talking about ethical reasons in a technical forum like RegExt might seem inappropriate but nonetheless think that often non-technical aspects have somewhat an influence on making technical decisions. My apologizes for the long post. Did my best to answer synthetically. Best, Mario Scott From: regext <regext-boun...@ietf.org><mailto:regext-boun...@ietf.org> On Behalf Of Mario Loffredo Sent: Wednesday, February 21, 2024 2:15 AM To: regext@ietf.org<mailto:regext@ietf.org> Subject: [EXTERNAL] [regext] Fwd: New Version Notification for draft-loffredo-regext-epp-over-http-03.txt 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 all, just submitted a new version of draft-loffredo-regext-epp-over-http. Here in the following the most relevant updates: 1. Has been made fully compliant with RFC 5730 2. Aligns with the structure and makeup of EPP over TCP (EoT) in RFC 5734 3. Fully pluggable transport for EPP with EoT 4. Verisign added as co-authors If the agenda of next meeting was not full, I would like to have a 10-minute slot to present the updates a bit more in detail. Any feedback is appreciated. Best, Mario -------- Messaggio Inoltrato -------- Oggetto: New Version Notification for draft-loffredo-regext-epp-over-http-03.txt Data: Tue, 20 Feb 2024 23:11:09 -0800 Mittente: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> A: Dan Keathley <dkeath...@verisign.com><mailto:dkeath...@verisign.com>, Daniel Keathley <dkeath...@verisign.com><mailto:dkeath...@verisign.com>, James Gould <jgo...@verisign.com><mailto:jgo...@verisign.com>, Lorenzo Luconi Trombacchi <lorenzo.luc...@iit.cnr.it><mailto:lorenzo.luc...@iit.cnr.it>, Lorenzo Trombacchi <lorenzo.luc...@iit.cnr.it><mailto:lorenzo.luc...@iit.cnr.it>, Mario Loffredo <mario.loffr...@iit.cnr.it><mailto:mario.loffr...@iit.cnr.it>, Maurizio Martinelli <maurizio.martine...@iit.cnr.it><mailto:maurizio.martine...@iit.cnr.it> A new version of Internet-Draft draft-loffredo-regext-epp-over-http-03.txt has been successfully submitted by James Gould and posted to the IETF repository. Name: draft-loffredo-regext-epp-over-http Revision: 03 Title: Extensible Provisioning Protocol (EPP) Transport over HTTP Date: 2024-02-20 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/archive/id/draft-loffredo-regext-epp-over-http-03.txt<https://secure-web.cisco.com/1KC6jFTUqMZOdJ6Po7DLUvEx4bz0ukpJdTEJRZF3dOUg7kFe2kdc4o1QYJSN-A5KRI4ajga3mx9j5Tsu1bi5St5Cx-uNAPP-zwZf_HA62hPwz_9eg00egGGltzTsNNaDizHZCJ8Qfk_M3mODWdby1rFTWL-6XrwRg7jx4CAvpx2iygBoEYzI8nSfyrndF2LS3hCQzMKD9uwb2RWuaAlkMVLJlEApMtxPPTF80K-Epc3S4QwSDz7vCBUTOBc9MwJ9HP1_piTsR_qHHxi4hxILn5bJxyanwkmh2HtYgTGuGrh4/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-loffredo-regext-epp-over-http-03.txt> Status: https://datatracker.ietf.org/doc/draft-loffredo-regext-epp-over-http/<https://secure-web.cisco.com/1WgECIVUjOIAsR-iTFVZofRj22KELPh2hR8mXqt4Ah1RMjkgzKWNgiSYSqjhaC9jGxs2cZbo78tWGijeobZgLB-BWiu0HdBadbM28kt_fooT0Q_E4EmZIh5b-HgRmf7cfA2xW3Jcui1LwreE8les4WDgk91q0c1uVcgT4n2MJgRthft2VpOGu1zCSQhc803p20A9z0q9dQS2MRPq9j8VEPAiJ9kgkXdsmP4hGRtbTga0F8_Wd1hHV1gdDQIDMu_txRFAC-fPjrizrYpJwVy50rv9zq5TeoIabT7CQTRAHU68/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-loffredo-regext-epp-over-http%2F> HTMLized: https://datatracker.ietf.org/doc/html/draft-loffredo-regext-epp-over-http<https://secure-web.cisco.com/1myv8wfhgRLMpRy662lU3LEpvfhXhlua4LmjwmAXrUQVz-SCnWY8NRdZrR5_sVzPKSomr0tAgTTlHV8IeplBfyGb4GuUKwmrSVbViybxm3Hs_9FFlnvoaoLt-eKH29bmOk-AuKVN05pZR_25b-GEHyQswHoPuqmPqqDR-0m4hfJBUNziLQkYTcmMvQWYvZP7jTRw2TH9A7mimZVgX-t_YHRknBIo6VIsRoYsnpLQ0pU9-pkSvfbV2ZBi9Z9AtE9nsBoXOXj-tkY3NKf4VlBN9MBPGWuHFuYEcHsifeI3a1WE/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-loffredo-regext-epp-over-http> Diff: https://author-tools.ietf.org/iddiff?url2=draft-loffredo-regext-epp-over-http-03<https://secure-web.cisco.com/12jI5T3lqP1oAgYgBbf_sR7EUAcL6VKmKLkg2ylT0ex8vwIKgjRHZ23Y0CD2WITQBuuLaQ2ksuqC0wswgmdwPrTl3Nh04Ww9tfhzLmUBBIFzgzTCXyQqSJUiSuo02WMuefoj4FvdkPczACJYDVH_FPgB9NSHwsBf3FusBpBfOuRG24bIj-uEGOxnDzLf3hXuChwIWRZrEn69Lkm45r8V_I_kLZaSfpxGhi-eCgCiKByBtLngPzbReNyOuB3Jytgp2e9Nna_6jLwOEwRx1pkntina57RexI6eqTRyG8JvT5h0/https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-loffredo-regext-epp-over-http-03> Abstract: This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a Hypertext Transfer Protocol (HTTP) connection. EPP over HTTP (EoH) requires the use of Transport Layer Security (TLS) to secure EPP information (i.e. HTTPS). The IETF Secretariat -- Dott. Mario Loffredo Senior Technologist 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/1o6c2NfEYxxsjKE7HUwmzvM8ny4xX34mbmrT8Rvm6sEhVQyO6-D2WG9MY_Pn8u_iLv2f8wSbItdKvJHo2eI5LEeEXaCG3n8Ue3Vq-bWbF0u0LcDvfg0KqAggaklI3IWf3b8c8PG1o5pxTztoUjDnzOhr3l2QSPDDl6VDYB8o-h3LXz2sOIcAGBY3zVtq3w4le9MLnwy0Re2HbVml2Or8y5Z0gzPzw3kmuQbPuPVvQZyNFvVKsHKQ-FYE2xXyonc9MJKBwn-A_2d5xnLNobAmVOZC8Lc_2uB_1qFVHMmfJGxw/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo> -- Dott. Mario Loffredo Senior Technologist 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/1FMArwksz_849iz9FyumjPDji-GzZShIR7_yIpseQkAVRKCGrbxFcJP9EMCESeSGDcy4tz3wf5nAV4N8pa0IbMlQ5uZeSzwCC2SGaUVBkDPJRLfnPIhBHlMPgjNRer-kS-RvZ47Txo0XwDM-oi4zt37Gkvfx21o2g9bFk6_xouo5n-txGgUYxy5gkbj2nyelQiIJ1MUpOae4KSw-QPrqMTlTz3wS6z6If6ji97TZwrPnC_PfDKPvG4HvaXFZo4P85CV_uWMnuC0fYIQNQeFA-w_ubybvBZdHz45Mn4jzhxPk/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
