Hi James,
thanks for ypur quick reply.
Please find my comments below.
Il 25/03/2022 16:45, Gould, James ha scritto:
Mario,
For #4 “Cookie vs. HTTP Connection”, you asked the question “can you
further clarify why we should opt for establishing the cookie at setup
of the connection and how should it be possible? For example, what
kind of request should be used to start the HTTP connection?”.
I implemented pluggable transports in the Verisign EPP SDK, which
included HTTP, HTTPS, TCP, and TLS. The Verisign EPP SDK does include
a client interface as well as a server stub implementation, so I was
able to see the transports from both sides. Support for HTTP and
HTTPS was removed once we stopped supporting EPP over HTTP. The
cookie is setup at the time of the HTTP or HTTPS connection. There is
no “request” that is used to start the HTTP connection, just like the
case for TCP and TLS. A network connection is made, which includes
the underlying TLS handshake in the case of HTTPS and TLS and the
cookie is setup for HTTP and HTTPS, and then the EPP application
protocol rides on top of it.
It seems to me a very low-level implementation.
Sorry but I stiil don't understand how cookies are returned. They should
be returned in an HTTP response that doesn't correspond to an HTTP
request. Correct?
If so, it seems to me uncompliant with what is stated in the first
paragraph of Section 2.1 of RFC7230:
HTTP is a stateless request/response protocol that operates by
exchanging messages (Section 3
<https://www.rfc-editor.org/rfc/rfc7230#section-3>) across a reliable
transport- or
session-layer "connection" (Section 6 <https://www.rfc-editor.org/rfc/rfc7230#section-6>).*An HTTP "client" is a program that establishes a connection to a server
for the purpose of sending one or more HTTP requests.* *An HTTP "server" is a program that accepts connections in order to
service HTTP requests by sending HTTP responses.*
Anyway, the approach normally followed by every HTTP implementer
leverages the services provided by an application server that
incorporates an HTTP server.
You don't need to manage HTTP connections, HTTP resquest/response
marhsalling/unmarshalling and other low-level details. You just need to
focus on the core of your server.
Similarly, on the other side side, after having configured an HTTP
client instance, a client simply builds and sends an HTTP request, and
then receives and processes an HTTP response.
If there is a HTTP transport for EPP, then it should be purely a
transport and not intermingle with the application protocol. There is
no need to directly tie a HTTP session with the established EPP
session. By keeping them separate, it makes it much easier for the
client and the server to have pluggable transports, where the
processing of the EPP commands including the hello, login, and logout
treat the transport as simply a connection with no intermingling of
session management.
If it means that you have to reimplement what has commonly been used for
years, it isn't clear to me how it could be much easier. On the
contrary, it seems to me much trickier, especially if you implement
EPP-over-HTTP from scratch.
If the goal is using the same approach for mapping every transport layer
without considering the peculiarites of each transport protocol and the
technology the implementers are accostumed to use to deal with them, it
doesn't make sense to me.
For example, I cannot figure out how HTTP load balancing could support
your solution.
Best,
Mario
--
JG
*James Gould
*Fellow Engineer
jgo...@verisign.com
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
*From: *regext <regext-boun...@ietf.org> on behalf of Mario Loffredo
<mario.loffr...@iit.cnr.it>
*Date: *Friday, March 25, 2022 at 11:01 AM
*To: *"regext@ietf.org" <regext@ietf.org>
*Subject: *[EXTERNAL] [regext] Comments to the feedback about
epp-over-http
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://secure-web.cisco.com/1tkPqD6aAMfTp6t6KppHDGdn0xpgOWSMeCqwZR-hs9Duph9SiceA0vCbaJJVqywNzcZscc6vUZkCPH9lCdtXq_nVJ3OfnNMz-XTQvhBuSBLsXa0VfO5ZNrGo47fSin8GRaQOWRSvSQP_7vRecBdddhF6L0Yqx3KcxAGpvdxpFCsPhLcd5bm-aVy3vTko6TfGBlohe2XEw3bwUmH-u56ZuZz50CUXUqA3YDFgBENAwPrLBjwdDxwgG1JFVGPZF_LEQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc2818>]).
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
<http://secure-web.cisco.com/1Af0lIvD4wj2TkngfEVwrFVEVRozLiVIU2m1Gi1AH1GN4-eWP-IREXsOLCh8OJ03YAxRNYqVCPHQSwgj-tMCyzvN3jokOBTIBx4-5n1pJdiRXxl-ShJCaHkCjGNPa8EA5qw4kPjkxIrFAy1qOTcPFhieqdc_xyu8yisYoXzily9ozVw3GZaUtkKrLnmnDJhlFv2LRTCTnw913LzH8bX-hB6FpPlyFi_0v2_H1NFCgZYjuu4pgUeOeIqQJRQwtzNLS/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.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
