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

[Pawel Kowalik <[e-mail]>]

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.
>
> 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.

Kind Regards,
Pawel