Security considerations for Federation API using RateLimit HTTP Headers

[Giuseppe De Marco]

In relation to federation endpoints, we may consider useful to express the indication to adopt HTTP Headers like RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset fields, allowing service limits and request policy, as defined in the following specification:

https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-ratelimit-headers-02

[Roberto Polli]

We recently released the 3rd version of the I-D https://www.ietf.org/archive/id/draft-ietf-httpapi-ratelimit-headers-03.html

I suggest to rely on the minimum set of specifications, that is

‌

RateLimit-Limit: 10
RateLimit-Remaining: 5
RateLimit-Reset: 60

and take good note of the security consideration related to information disclosure and denial of service linked below.

https://www.ietf.org/archive/id/draft-ietf-httpapi-ratelimit-headers-03.html#name-information-disclosure

https://www.ietf.org/archive/id/draft-ietf-httpapi-ratelimit-headers-03.html#name-denial-of-service

[Michael Jones]

The ratelimit draft is not yet an RFC, and therefore subject to change. I’m reluctant to take a dependency upon it until it becomes an RFC.

I propose that we close this issue on that basis.

[John Bradley]

This is still a WG draft. If we reference a draft that is changed by the final RFC then we can create problems down the road.

The idea of using these headers is probably reasonable. However, it would be better to add this only after this becomes an RFC so we have a stable reference.

‌

[Michael Jones]

Placed on hold until the RateLimit spec becomes an RFC.