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