I am not in favor of weakening the security posture of EPP. If one security mechanism is to be downgraded from a MUST to a SHOULD, there needs to be a replacement of it with another security mechanism that is a MUST which keeps the security posture of EPP at the same or greater level.
-andy On Thu, Feb 22, 2024 at 1:56 AM Mario Loffredo <mario.loffredo=40iit.cnr...@dmarc.ietf.org> wrote: > > 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> On Behalf Of Mario Loffredo > Sent: Wednesday, February 21, 2024 2:15 AM > To: 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: > > Has been made fully compliant with RFC 5730 > Aligns with the structure and makeup of EPP over TCP (EoT) in RFC 5734 > Fully pluggable transport for EPP with EoT > 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 > > A: > > Dan Keathley <dkeath...@verisign.com>, Daniel Keathley > <dkeath...@verisign.com>, James Gould <jgo...@verisign.com>, Lorenzo Luconi > Trombacchi <lorenzo.luc...@iit.cnr.it>, Lorenzo Trombacchi > <lorenzo.luc...@iit.cnr.it>, Mario Loffredo <mario.loffr...@iit.cnr.it>, > Maurizio Martinelli <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 > Status: https://datatracker.ietf.org/doc/draft-loffredo-regext-epp-over-http/ > HTMLized: > https://datatracker.ietf.org/doc/html/draft-loffredo-regext-epp-over-http > Diff: > https://author-tools.ietf.org/iddiff?url2=draft-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 > > _______________________________________________ > 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
