Hi James,
here are again my responses below.
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
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
*From: *Mario Loffredo <mario.loffr...@iit.cnr.it>
*Date: *Wednesday, March 30, 2022 at 8:28 AM
*To: *James Gould <jgo...@verisign.com>, "regext@ietf.org"
<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
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com
<http://secure-web.cisco.com/1fmebMbwOUgdo-WyMaIsLZ1SH_XvKhWjFsvhnqk29yAQF2aCDU1bQl0rsVTtHPLG2BkDpIZ4MRjQsieE6r3TIX1L0ZZ7ekjXpaFeAZJDrC_Po6vguQRG0GQxM_3QyDX71rQvTjctNCis34Eb3FlrargkQgR5XO62fk7y3kgDfQM3nIcfYBm16faG667F4c9QVNETKgFbhSeqgY14mUJuMb_4AAv736hwPtIFaeVSRpYMMCGp1ZN1ut0cVsLLpuUa2/http%3A%2F%2Fverisigninc.com%2F>
*From: *Mario Loffredo <mario.loffr...@iit.cnr.it>
<mailto:mario.loffr...@iit.cnr.it>
*Date: *Tuesday, March 29, 2022 at 11:00 AM
*To: *James Gould <jgo...@verisign.com>
<mailto:jgo...@verisign.com>, "regext@ietf.org"
<mailto:regext@ietf.org> <regext@ietf.org> <mailto: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
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com
<http://secure-web.cisco.com/1EaISbPmlOZzCKgUuIbmDA4rr-y-fT4gnfY0xiPotQBQC-vNT5PBKwJ1STPDcTK6y65BpvZgT5XqntG_ZysxPVZX8XjGyZXOW-P8nL-bdEwKNOkYvtyGhf1-PjTUP3gKykqkaX6QProvtyfCBkgC_m9J8xcE7yHeQ2_JycG85cc1JtO74KeQ6D9bsl9tHxNpgzRFA-IE_CZkI01GCY0-9LRrY2Tdd3mwPuBMAXYl7okYjJdszZFa2vwEdisCoAWAN/http%3A%2F%2Fverisigninc.com%2F>
*From: *Mario Loffredo <mario.loffr...@iit.cnr.it>
<mailto:mario.loffr...@iit.cnr.it>
*Date: *Monday, March 28, 2022 at 6:59 AM
*To: *James Gould <jgo...@verisign.com>
<mailto:jgo...@verisign.com>, "regext@ietf.org"
<mailto:regext@ietf.org> <regext@ietf.org>
<mailto:regext@ietf.org>
*Subject: *[EXTERNAL] Re: [regext] Comments to the feedback
about epp-over-http
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?
JG: HTTP is being defined as a transport for EPP, so it should
be treated as such. The setup and tear-down of the HTTP
connection, includes the setup of the cookies that is used for
HTTP session tracking. When a connection is made to the EPP /
HTTPS server, the TLS connection is first established via the
TLS-handshake and the HTTP session is established via setup of
the session cookie (e.g., JSESSIONID), which then enables the
server to maintain state. State such as tracking failed login
attempts and timeouts (idle / command / absolute), which will
result in a drop in the HTTP session / connection when the
login attempt threshold is exceeded. At the application
layer, a HTTPS connection is treated in the same way as a TLS
connection, where the transport handles the framing and the
connection state, and the application layer returns the EPP
Greeting when the connection is setup and drops the connection
with a EPP logout occurs or other EPP session conditions
(e.g., exceeding timeouts). The HTTP session cookie is
returned in all the HTTP responses. There is absolutely no
intermingling of the transport layer (HTTP) with the
application layer (EPP) other than making a connection
available to read and write framed packets and the ability to
close the connection when needed.
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://secure-web.cisco.com/1HLyHB_XdFEjfXQwGFkG0LZSLLnG4WFNvmZ-TNjfY6OfIaLTmL1biILbx72S_U5GmIiJtbpg0x39TJ52od6XvJJ-XGkebzBiEggAwQ42v85iZAXdc75eWbMUFwdy__GSQvGqoc_3jBcXvzaJksIZ9kIaGCObuN4sNz3NQqB4Gsr44Gdw9c4U6nDx9j_3kyp9hk3Za8zxK-CiPfgUAyNLhZ53ksc5Ae9PHvSSpW9kjbB9txLir0tvwL_pUPzDpJS2Y/https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7230%23section-3>)
across a reliable transport- or
session-layer "connection" (Section 6
<https://secure-web.cisco.com/1vvJc-KSBR_KweDtRuo-dlLx6E_Z9fnj9TRqKJPKmI-z_MzpIyDJWDzfwvS180O64nU4M_K-HwHtvVlPkTyfnMVQ8I50S_dOCSrwzrW9QXz8ckfa9Yj0UZmgPk4aOBSCgpizCtKhPiufait2c-bik8SwDi5FGriXh2QetIDOP_N5qvkVGUCrJ7Agu0Kz55-5IRTrJpPK2rtdg6AYpfgj-5oaNCOjZ9kZcI233HN_HumLXDVcKmYklOTTqh_7mGPwt/https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7230%23section-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.*
JG: I don’t see how using HTTP as a EPP transport would be
considered uncompliant with RFC7230. Below is the flow of
using HTTP as an EPP transport:
1.Establish TCP connection
2.Establish TLS session via TLS-handshake
3.Establish HTTP session via setup of the HTTP session cookie
(e.g., JSESSIONID)
4.Return EPP Greeting in framed HTTP response with the session
cookie (e.g., JSESSIONID)
5.Support HTTP requests in the form of framed EPP commands
that are returned in HTTP responses in the form of framed EPP
responses.
6.EPP session ends that drops the connection (HTTP / TLS / TCP)
[ML] I apologize James but I still don't understand how it would
be possible to return an HTTP response including the EPP Greeting
and establish a session cookie without having previously received
an HTTP request or, to say it better, how it would be possible at
the abstraction level provided by all the libraries and frameworks
supporting HTTP communication on both client and server side.
Being HTTP used as a purely transport (L4) protocol but not as a
request/response (L7) protocol, the implementation wouldn't be
compliant with RFC7230.
The same concept is also repeated in Section 2.1 of RFC 2818 "HTTP
over TLS":
The agent acting as the HTTP client should also act as the TLS
client. It should initiate a connection to the server on the
appropriate port and then send the TLS ClientHello to begin the TLS
handshake.*When the TLS handshake has finished. The client may then*
* initiate the first HTTP request.* All HTTP data MUST be sent as TLS
"application data". Normal HTTP behavior, including retained
connections should be followed.
JG: The first step is a HTTP GET request that establishes the HTTP
session and receives the EPP Greeting in the HTTP GET response,
which includes the HTTP session cookie. Subsequent requests can
use a HTTP POST for the EPP command and receive the HTTPS POST
response for the EPP response. The EPP SDK Stub Server supported
use of either the HTTP GET or POST and if a HTTP session did not
exist, it returned the EPP Greeting in the HTTP response with the
HTTP session cookie. After the HTTP session was established, the
responsibility of the HTTP layer was strictly to accept HTTP
requests, which works as the packet framing of TCP, and places the
EPP responses in the HTTP responses. The HTTP request and
response is fully compliance with the RFCs, since the connection
is a request with a greeting response, and subsequent EPP command
and responses are handled in HTTP requests and responses.
Connection state is maintained in the HTTP session, which would
deal with issues like a failed login threshold and timeouts (idle
and command). The Verisign EPP SDK includes an packet assembler
class, which is configurable, which deals with the marshaling and
unmarshaling of the commands and responses of the underlying EPP
transport, which included assemblers for TCP, TLS, HTTP, and
HTTPS. You could even setup client session pools using the
assembler of your choice, where a single client could interface
with an EPP/TLS server and an EPP/HTTPS server, all by specifying
the desired EPP transport. If you are to mix the EPP protocol
with the underlying transport layer, then it would remove the
ability to plug in the desired transport.
[ML] Now everything is clear to me. I didn't udenstrand your previous
message because you omitted that a client starts the HTTP session via
HTTP GET :-)
Both .it and .pl implement only the POST method. HTTP and EPP
sessions are started together and linked each other after a Login
command due to the following reasons:
1. The session ID is the unique key to retrieve EPP session information
JG: That intermingles the application layer with the transport. Do
you support EPP / TLS in parallel with EPP / HTTPS? If so, this
intermingling would pose an issue. The EPP session id should be
independent of the HTTPS session id.
[ML] If I'm sure to generate every time a unique session ID, it doesn't
matter if I support EPP/TLS together with EPP/HTTPS or not. It will be
unique anyway. Don't understand why I should generate two unique session
IDs, one to be used as session cookie and one to be used as EPP session
identifier and then link them together ?!
2) Except for the client IP address, the information that a server
must maintain as long as an EPP session lives is included in the Login
request (i.e. the registrar name and the XML namespaces)
3) It's very unlikely that an EPP client doesn't know the services
provided by a given EPP server
JG: Does this mean that .it and .pl doesn’t provide the EPP Greeting
when the connection is established? Returning the EPP Greeting at the
time of connection is a requirement in RFC 5730 “An EPP server MUST
respond to client-initiated communication (which can be either a
lower-layer connection request or an EPP service discovery message) by
returning a greeting to a client.”.
[ML] Since RFC5730 states that Greeting can be returned in response to
an Hello either, we are compliant.
4) As a consequence of point 2 and 3, why should a client submit a
meaningless HTTP request to the server before submitting the Login
command to start an EPP session?
JG: The EPP transport needs to support what is defined in RFC 5730.
The connection is established and the server returns an EPP Greeting.
[ML] The HTTP connection might be established at any HTTP request the
EPP client sends to the EPP server. If the interval between two
subsequent HTTP requests exceeds the Keep-Alive timeout set b the HTTP
server, the HTTP connection is established again. The session cookie is
the mechanism that allows an HTTP-based EPP server to trace all the HTTP
requests back to an EPP session.
An HTTP-based EPP server is able to manage requests, responses and
sessions. It cannot manage connections because they are managed
automatically at a lower layer.
5) RFC5730 states that an EPP session starts with a <Login> command
and RFC6265 states that servers maintain stateful sessions over HTTP
by setting the session cookie. Hence, It seems natural to me that
servers start an HTTP session and set the session ID after a
successful Login command.
JG: The EPP session may start with the login command, but the
transport session is established ahead of the EPP session being
established.
[ML] In HTTP, a physical transport session doesn't exist. The stateful
session is simulated via the session cookie over single HTTP
connections. If the Keep-Alive is on, a TCP connection can be reused to
issue multiple HTTP requests.
But this is not guaranteed.
6) Application protocol sessions on server side normally start after
authenticating the client (please note that this is exactly what we
are pursuing in RDAP)
JG: You really need to follow the flow defined in RFC 5730 for an EPP
transport. My recommendation again is to set the HTTP session id at
the time of the connection and have the server return the EPP
Greeting, just like what occurs with EPP over TLS. The transport
should not intermingle with the application protocol, which enables
the pluggable of transports on the client-side and the server-side.
7) It seems inefficient to release an HTTP session from an EPP session
because it can result in wasting resources to maintain possible
useless HTTP sessions.
JG: I don’t see the wasting resource use case here. When a client
makes an EPP over HTTPS connection to the server, the HTTP session is
established and EPP rides on top of it. The first EPP packet sent is
the EPP Greeting by the server. The server can establish policies
such as maximum failed login attempts to drop the connection.
[ML] So could a client send tons of HTTP GET without being blocked?
8) If an HTTP session is not established after an authentication, IP
whitelisting is a must instead of a recommendation. Even if in general
registries require registrars to declare their own clients' IP
addresses out-of-band, this is not an absolute constraint and the same
IP address might be used by multiple registrars. For the same reason,
you cannot limit the number of HTTP sessions per registrar thus
mitigating the risks pointed out in point 7.
JG: IP whilelisting can be aggregated in the ACL and then checked
during the login command.
[ML] See my previous comment.
Regarding to the EPP commands, other than Hello and Login, that don't
include a valid session ID, think it's better the server returns an
EPP error ("Command use error") instead of a Greeting response
including a new session ID.
JG: If you’re not returning the EPP Greeting at the time of the
connection, you’re not implementing EPP. The definition of an EPP
transport needs to fully support the EPP protocol defined in RFC 5730.
[ML] This is exactly what happens also in your implementation. An HTTP
connection can be established by issuing an HTTP GET but it might happen
that a new one is established by issuing the subsequent POST for the
Login command.
In the first case, your server returns a Greeting response while in the
second your server retuns the Login response. In both cases, a new HTTP
connection is created.
Even if you set the EPP session timeout equals to the Keep-Alive
timeout, you can be sure that two subsequent requests are using the same
HTTP connection.
You can realize that if you control the HTTP connections but these means
that you are working at a programming level that doesn't correspond to
that provided by libraries and frameworks supporting HTTP on both client
and server side.
My personal opinion is that such an interpretation of EPP over HTTP is
actually impractical.
Have a question: how do you figure out the case where a client issues
two Login commands with the same valid session ID previously received
via the GET response? I imagine that only one would be accepted.
If so, the mapping between an HTTP session and EPP session exists also
in your implementation. It occurs when the EPP session is created
instead of when the HTTP session is created.
JG: The HTTP session maps to the state held on the server-side, which
would include items like the client IP address, client certificate,
and other attributes that can be used along with the passed user name
and password in the login command. The EPP HTTP transport should
handle the same features as EPP TCP in RFC 5734, which includes the
connection requirements (e.g., TLS) and the method of packet framing.
In the case of HTTP, there is the need for establishing the HTTP
Session Id and using the HTTP request and response packets for
containing / framing the EPP packets.
[ML] Why should a client certificate be stored in the EPP session?
Best
Mario
Best,
Mario
7.
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.
JG: An EPP client or server should be capable of reusing all
the same command and response processing without dealing with
transport specific logic. The transport layer can be built as
a layer that is pluggable. A client can configure the
transport to use on a per-server basis, and the server can
reuse the same command processing logic whether running on top
of TLS or HTTPS, since TLS and HTTPS are purely transports.
[ML] It's unclear to me how two communications working at
different layers could be handled in the same way. As I wrote in
my previous reply to Matthias, the approach proposed aims to
preserve EPP commands semantics so that the EPP server core should
be the same regardless the fact that it is supported by HTTP or TCP.
JG: It's very straight forward to make the EPP transport pluggable
if you treat the EPP transport as purely a transport. The
application layer does need to go through a pluggable transport
layer to enable the transport layer to frame, and
marshal/unmarshal the commands and responses. In the case of the
Verisign EPP SDK, that assembler layer took care of it for TCP,
TLS, HTTP, and HTTPS. The EPP command processing is not dependent
on the transport layer, meaning the EPP command processing layer
doesn’t need to be concerned with setting a HTTP session cookie
upon a successful EPP Login or handling the EPP Hello in any
special way as it relates to HTTP cookies. EPP is a stateful
protocol, where the underlying transport needs to support being
stateful. If the desire was to move towards stateless, then
you’re not defining an EPP transport but a new EPP protocol. My
recommendation is to keep the EPP over HTTP simple and establish
the HTTP cookie at the setup of the HTTP connection and separate
the EPP sessions from the HTTP session.
Mario
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.
JG: The HTTP transport for EPP can easily be defined as a pure
transport, which provides a connection for the application
layer to leverage in the same fashion as TLS. The load
balancer can leverage the TLS session id to route to the EPP
gateway and in the case of HTTP, the HTTP session can be used
to route the request to the appropriate application server
that contains the connection state. Some HTTP application
server proxies leverage the HTTP session to route the requests
to the application server that contains the HTTP session and
state. You need to establish the HTTP session when the
connection is established to support the needed routing.
There are other load balancing options, but by simplifying EPP
over HTTP to have HTTP as purely a transport, it provides
maximum flexibility in routing and maximum pluggability of
transports (TCP, TLS, HTTP, HTTPS).
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://secure-web.cisco.com/1ojxKstUEceETR7pe4khQ2dcwgGUwoOuZu4vhcT-TZcTCCpM93jXl6eq5i46tfTPt6lE9M6FO7hPqFZQVgxN5su1ozpEIXrOmp6SzB5kEB5SXCcRaJIg-vRb2B_SxGeDcgjxTqmZNEVO_Z0LtwZEFTLbzsLhmMMT-MlZ9pX7rpBY6Q8K0RxXyklhUEXCOqlJ0RMcZX2tEZNHp0Pr6XFhgw4X7OA0XCs0tk_jqiJbYMrkAFF0PXiAItfCmm_MR8whC/http%3A%2F%2Fverisigninc.com%2F>
*From: *regext <regext-boun...@ietf.org>
<mailto:regext-boun...@ietf.org> on behalf of Mario
Loffredo <mario.loffr...@iit.cnr.it>
<mailto:mario.loffr...@iit.cnr.it>
*Date: *Friday, March 25, 2022 at 11:01 AM
*To: *"regext@ietf.org" <mailto:regext@ietf.org>
<regext@ietf.org> <mailto: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
<http://secure-web.cisco.com/1OpUT5efcRPCKu9ZmpfyFmbeoIexTqMIlduFKl7VTUSeET1W3oogufCAfJPPw-WSQ0iyo_wkztY_7M69qw0yf13C4w7OWB_Zk5w2FsV-GGCSLot8lFQdslU0DvCpCTw9FjZr0AsFsubGH-kToYrLxzzEj7vGDKuxIFxPK92P5bu2CDOE4UFtRPRGvu9rzX83rks8X2le_j1uSS1SD5B8CyvSp0tsne0HWMS5luho_DIhdOil7-0a_7ZX6CQA08GQq/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
<https://secure-web.cisco.com/16jl36WEWq0s-czRNUY5mezogTB1s8eM6-POsf3osvBxTtShse2Gx3vayC92AUxQ8ebDwE9Ob8SzhMcrkTCHnZy_RbpQlkSPKyyG9v1LOvWmmr2bX-q2Kwz-52tKvzlBlfgMU_rKnCsIFS9e53n9Fl1sqideuhzE2Qvq05_MQ6tGzuKP1z0P4vYyDR8QmVl4xwlz-BKFhZLijpQYz9CLe61qg3JAC0a2ldUiZMLUwjnSSssMNXvvVibSRdv-9l9yg/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>
--
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/1yKvefSSzzB1xtPf0Zt9UvXnOkA28n5LvF1HkMnNZqV6Dwz7x7ZD06GbmS94ZAQwsmSA6iszQPAkGi5fNCSMjCHwEbful0vNQc0bfu7a2ydpIkKyqCYgjHlBp7I_-3eCZXAtMTjU_xfTEae9EnXNbksctYNkGyOsHDR02jSoOeVLa3lgW8hWUZ20zgxxFQlt_HdsERDtOQY4EoiE3orLFHDV3wtSA-ChHIYVp1pfMvU2aCEBQ3tWEhFOLp740jUPP/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
<http://secure-web.cisco.com/1pp2UVbYq0m0PdgNAIf-MFBBPlI6rgwJb-nl0OyxKTaZvJklLUlXEVPn3qvn6ziLbUr86nSYHSn9PLRlT1wKKUgtGjJOdnJ8Ghkk3hlYjxMa4J4AaIOBZ7WvzWPIEvoHPBVb2TdHFIKvtiJkT5ev0nRTy-ErBgM9XRxiNe_p-wkwdeLKKqJWcyzpKSrlr3WZKQaTzmyHAwtIPMymiYesdU2YUhfSeGkOO4qysnLCFQpp6nqMFwr28xmvjE8p7Rz8v/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
_______________________________________________
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
