[rpp] Re: [regext] Re: draft-ietf-regext-epp-https-02 early Httpdir review

[Mario Loffredo <[e-mail]>]

Hi Pawel,

again my comments inline.

Il 17/03/2026 16:10, Pawel Kowalik ha scritto:
>
> Hi Mario,
>
> On 17.03.26 15:20, Mario Loffredo wrote:
>>
>> Hi Pawel,
>>
>> see my comments inline.
>>
>> Il 17/03/2026 12:25, Pawel Kowalik ha scritto:
>>>
>>> Hi Mario,
>>>
>>> On 17.03.26 12:06, Mario Loffredo wrote:
>>>>
>>>> However, the risk of managing too many sessions or maintaining 
>>>> unused sessions is common to all mechanisms based on 
>>>> server-generated secrets to prevent clients from authenticating on 
>>>> every request. To be clear, EoH sessions = RPP JWTs.
>>>>
>>>> The mitigation measures are the same: limit the number of 
>>>> simultaneously active secrets and optimize secret lifetime.
>>>>
>>> This is only true if the tokens are persisted. This must be true for 
>>> opaque tokens, but is not true most of cases for rfc7523 JWT tokens. 
>>> These tokens are self-carrying and only resource which can be 
>>> exhausted is the token endpoint itself. A sane OAuth2 server will 
>>> rate limit token generation per client to prevent that.
>>>
>> [ML] It's true but with two drawbacks. A JWT once created remain 
>> valid until its expiration time, making them vulnerable to misuse if 
>> stolen, even after a user logs out. Security risks persist throughout 
>> their lifespan. Therefore, in order to mitigate these risks, it's 
>> crucial to finda good compromise between the lifetime of a JWT and a 
>> sustainable rate of requests.
>>
>> Briefly, JWT works well in distributed systems, but it introduces new 
>> risks compared to session-based models, especially around token 
>> leakage and revocation.
>>
>> Security concerns related to JWT are also mitigated by the nature of 
>> the REST service. This is why I'm in favor of using JWT in RDAP but I 
>> see more disadvantages in using them in a provisioning protocol.
>>
>> To be clear, I'm not saying JWTs shouldn't be used, but I'm showing 
>> the pros and cons of using them.
>>
>> The other disadvantage is the additional effort required for clients 
>> to manage tokens in general, compared to HTTP sessions. Clients must 
>> register with the authentication server, access the token endpoint, 
>> obtain the token, and store and refresh it unless they want to 
>> request a new one for each request.
>>
> [PK] My point was not about proving which one is better. Just the 
> statement was not correct about usage of JWTs, that's all. I agree 
> with all you say and the operator of RPP server would have to make 
> some choices and take trade-offs. I think only non-negotiable factor 
> written down in requirements is that RPP must remain stateless.

[ML] I agree with you. As I wrote, I have no prejudice against the use 
of JWTs and tokens in general. Like you, I supported the proposal to use 
them in RDAP authentication, and at .it, we currently use them for 
authentication to some REST services.

I try to objectively weigh the pros and cons of their use.

>> Managing an HTTP session is much less complex than managing a JWT.
>>
>>> For http sessions is different, as usually some server-side 
>>> resources are created to manage the session. There are solutions 
>>> that carry the same properties as JWT tokens, where cookies are 
>>> basically encrypted tokens with full state of the session (and 
>>> nothing on the server), but I don't know how applicable it is to 
>>> EoH. If the session state may change during the session, then strict 
>>> ordering of the requests is required to prevent stale session cookie 
>>> usage.
>>>
>> [ML] The information stored in the EPP session is basically that 
>> negotiated at the time of EPP Login and remains immutable for the 
>> duration of the session.
>>
>>     -  An <options> element that contains the following child elements:
>>
>>        -  A <version> element that contains the protocol version to be
>>           used for the command or ongoing server session.
>>
>>        -  A <lang> element that contains the text response language to be
>>           used for the command or ongoing server session commands.
>>
>>        The values of the <version> and <lang> elements MUST exactly match
>>        one of the values presented in the EPP greeting.
>>
>>     -  A <svcs> element that contains one or more <objURI> elements that
>>        contain namespace URIs representing the objects to be managed
>>        during the session.  The <svcs> element MAY contain an OPTIONAL
>>        <svcExtension> element that contains one or more <extURI> elements
>>        that identify object extensions to be used during the session.
>>
> [PK] ok, if this is all embedded in the cookie  (+ some client 
> identification) and the cookie does not change during the session then 
> server may not need to keep track of open sessions.
>
> But, same time would it be the client who assures order of request 
> processing? The "HTTP transport" cannot assure that any more, because 
> parallel requests with the same cookie will be still legit.
>
[ML] EoH draft specifies that the cookie contains the session 
Identifier, not the entire session.

Regarding the order, James, in reply to Maarten, has already proposed a 
solution to your question.

In any case, in normal operation, a client sends a new request after 
checking the response of the previous one, stating with the EPP Login 
and ending with the EPP Logout.


Best,

Mario

> Kind Regards,
> Pawel
>
-- 
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: [phone]
Web:http://www.iit.cnr.it/mario.loffredo