[Rats] Re: draft-ietf-rats-coserv-07 early Httpdir review

[Paul Howard <[e-mail]>]

Dear Lucas and CoSERV-ers,

Lucas, thank you once again for the comprehensive review of CoSERV.

Thomas Fossati and I have met last week to do a walk-though of the issues raised, and I’d like to summarise the changes to the draft text that we are proposing to make to address them.

I’ll top-post the suggested changes per-issue. The full issues from the original review are also quoted below for cross-referencing.

Lucas, please feel free to alert us if you think that the suggestions are not sufficient to address the issues from your review. Please note also that we had one clarification question for you around ISSUE 9, which is included below, so we’d specifically appreciate your attention to that.

CoSERV co-editors, please also review the following suggestions. Unless I hear otherwise, I will begin to prepare a PR to the draft with these changes applied.


ISSUE 1: Privacy concerns of the caching design wrt HTTP caching

SUGGESTED CHANGE: We will add the oracle cautions to Privacy Considerations in the draft and suggest the use of the no-store or private Cache-Control directives for queries related to small anonymity sets.


ISSUE 2: Safe methods and HEAD

SUGGESTED CHANGE: We will explicitly disallow HEAD method support as a “MUST NOT”, instructing servers to return the 405 status code if this method is attempted. The rationale is that CoSERV providers are not general-purpose servers. CoSERV is a specialised protocol. There is no value in the HEAD method for the case of a CoSERV query.


ISSUE 3: Validators and ETags

SUGGESTED CHANGE: Agree that the current illustration of ETags in the example diagrams is not quite correct, so we will amend the diagrams to make it clear that the ETag comes from the origin server and is propagated elsewhere. We will also recommend that origin servers should compute ETags in such a way that they are based on the unsigned content, in order to avoid the accumulation of cache entries that are identical except for their signature.


ISSUE 4: Query size bounds, URI privacy and QUERY method

SUGGESTED CHANGE: We will caution on the URI privacy issues in the Privacy Considerations section. We will also document the potential 414 status return code for GET operations. The QUERY method looks like a good fit for CoSERV, so we will specify it as an optional alternative, but not require all CoSERV providers to support it.


ISSUE 5: Freshness

SUGGESTED CHANGE: We will strongly encourage (with a “SHOULD”) that CoSERV origin servers set Cache-Control headers explicitly, so to avoid infrastructure layers defaulting to controls that might be unsuitable for the content lifetimes.


ISSUE 6: Discovery content negotiation and response caching

SUGGESTED CHANGE: We fully expected that discovery documents would be cached by clients (and our running PoC code demonstrates exactly this pattern), so we will make sure this is explicitly called out in the draft text. We will also add the statement that the server MUST support both CBOR and JSON formats of the document, along with the recommendation to use the Vary header to avoid serving the wrong content type from cached responses.


ISSUE 7: Accept looseness

SUGGESTED CHANGE: For the GET method to fetch the discovery document, there are no special semantics beyond standard HTTP content negotiation, including the use of defaults. Therefore, the redundant sentence about negotiation can be removed. However, this is distinct from the method to execute a CoSERV query (the request-response transaction). For this case, the requirements are a little stronger, because there is no sensible default Content-Type. We will strengthen the text in this case to say that the client MUST supply exactly one supported media type from among the capabilities in the discovery document. This means that a 406 response should, in theory, never occur. But we will continue to document the potential for 406, and also indicate that the server MAY provide the permitted Accept types in the response headers.


ISSUE 8: Error Content-Type broadness

SUGGESTED CHANGE: We will alter the wording to make it clear that error responses are a requirement on the origin server, but cannot be assumed by clients in the presence of infra layers.


ISSUE 9: Rate Limiting

SUGGESTED CHANGE: We will delete the rate limiting example and explain that rate limiting could (and typically would) occur in infra layers rather than at the origin server. Error details beyond the HTTP status code will not be prescribed.

CLARIFYING QUESTION: We don’t understand the comment “the ‘MAY’ is an issue and needs to be rephrased”. The current text indicates that the server MAY include a Retry-After for rate-limited cases. We don’t understand what’s wrong with this text. It seems to be sensible even in cases where rate-limiting is controlled by infra layers.


ISSUE 10: Truncated Examples

SUGGESTED CHANGE: Rather than extend the examples with complete base64-encoded queries (which would add a lot of textual bulk), we propose instead to indicate typical sizes for queries, from which the reader will be able to infer what a typical CoSERV URI would look like in practice. We can add this information in a new paragraph, which can also be used to indicate the potential use of QUERY instead of GET (see ISSUE 4 above).


ISSUE 11: Redirects

SUGGESTED CHANGE: We would not expect redirects to rewrite the actual query (which is the leaf element of the path), even if other parts of the URI path are affected. We can add some explicit text to this effect if that helps, but we don’t feel that CoSERV requires any specific handling for redirects.


ISSUE 12: Inconsistent discovery responses

SUGGESTED CHANGE: We will align the CBOR and JSON examples for greater clarity.


ISSUE 13: Caching examples and time

SUGGESTED CHANGE: We will fix the lower diagram in the caching example, adding an Age field alongside the existing Cache-Control header field.



On 15/08/2026, 05:18, "Lucas Pardue via Datatracker" <[e-mail]> wrote:

Document: draft-ietf-rats-coserv
Title: Concise Selector for Endorsements and Reference Values
Reviewer: Lucas Pardue
Review result: Not Ready

[…]

# Major issues

1. Privacy concerns of the caching design wrt HTTP caching

IIUC this topic has been discussed in the WG. However, I think the current text,
in combination with fundamental design choices wrt HTTP caching, leaves a
potential adjacent privacy issue.

A CoSERV query is serialized into a URI using a well defined, **deterministic**
mechanism and sent in an HTTP request e.g. GET
/coserv/{base64url-encoded-string}. The protocol expects this URI to be used as
a cache key. The data that forms the input to the CoSERV query can contain
sensitive information for a small anonymity set. In my simplified comprehension
of RATS terms, an `instance` can identify a single unique device or component,
while a `group` is a group whose anonymity is only as good as its size.

While the document addresses some of this topic in RATS terms, the use of
generic HTTP caching, IIUC, introduces some potential new threats. The HTTP
cache itself can become an oracle; the timing of serving responses can indicate
if someone has already queried the information. An attack could come in the form
of scraping a list of predictable identifiers (correlating to a deterministic
URI) to gain intel on instances or groups based on the performance of HTTP
results. A generic HTTP cache makes itself available to any generic client to
perform such an attack.

The AI tooling suggests that this has been touched on in issue 81 and 67.
However, the text following text in the document is likely insufficient to
address the oracle problem:

> Although reusing cached responses is generally desirable, clients that need to
> bypass the caching infrastructure can do so by specifying Cache-Control:
> no-cache in their requests.

This cache control directive affects one aspect, skipping any cached value and
going to origin. However, that doesn't prevent the issue. The result of the
no-cache request **can be stored in the cache**. Its unclear to me if the
authors meant to specify the usage of the **no-store** directive. Importantly,
other clients can do other things; if they can probe a shared cache with private
info, a side channel exists.

A possible improvement is to lean on HTTP's toolkit more. The "private"
directive might be appropriate for very-fine-grained information in the query
such as instance or group. This would stop caching for those queries while
allowing broader queries to benefit.

If the WG/authors agree this oracle is an issue but cannot find consensus on a
standard mitigation, then security consideration text that highlights the
threats and HTTP toolkit might be sufficient. Sometimes its really up to
deployments to decide on the privacy/performance tradeoff. The important thing
is the ensure no naive use of shared caching; an "off-the-shelf" caching HTTP
server might just do that.

2. Safe methods and HEAD

The document states "only safe HTTP methods are used" and goes on to specify how
GET is used to make queries. But this is not an s/methods/method editorial-level
matter.

RFC 9110 states "All general-purpose servers MUST support the methods GET and
HEAD. All other methods are OPTIONAL.".

This document is silent on HEAD, which is problematic. HEAD is functionally
equivalent to GET ("SHOULD send the same header fields in response to a HEAD
request as it would have sent if the request method had been GET), implying that
a CoSERV server would run the same processing as the GET request. Is that
desirable?

There's also some deeper consideration to make wrt caching. Various freshness
validators _could_ be used with GET. However, RFC 9111 Section 4.3.5 states how
HEAD requests interact with caching in the absence of conditional GET.

This issue is somewhat elevated by the lack of explicit guidance on validators,
see (3).

For the purposes of CoSERV, it may be appropriate to disallow HEAD. This would
prevent clients from having a cheap way to trigger work on the server (i.e. a
low-bandwidth CPU amplification attack). Safe methods can be trivially replayed
and things like 0-RTT early data could make a server more liable to attack.

4. Query size bounds, URI privacy and QUERY method

This is probably going to be one of the more controversial comments.

The CoSERV HTTP binding requires converting a query into a base64url string
carried in the URI. I don't know how big the underlying query data tends to be
in practice but the HTTP ecosystem does tend to limit the size of URI they
support. IIUC query size is unbounded but there may be real practical limits to
sending them via HTTP.

The recently published QUERY method (RFC 10008) summarizes the potential
problems quite well:

> when the data conveyed is too voluminous to be encoded in the request's URI,
this pattern becomes problematic:

>  *  size limits often are not known ahead of time because a request can pass
through many uncoordinated systems (but note that Section 4.1 of [HTTP]
recommends senders and recipients to support at least 8000 octets),

>  *  expressing certain kinds of data in the target URI is inefficient because
of the overhead of encoding that data into a valid URI,

>  *  request URIs are more likely to be logged than request content and may
also turn up in bookmarks,

The simplest thing to do is consider adding some text to highlight the potential
failure mode. A 414 (URI too Long) mention might be useful. You may also want to
highlight the privacy issues with logging URIs that contain any potential PII.

Possibly unpalatable: consider adding/substituting support for QUERY. This would
allow you to have a safe method to send the query in a more efficient binary
representation. A valid reason not to adopt QUERY wholesale at this time is that
support is still rolling out. A future binding might want to consider it though,
especially if you need larger queries and bump into limits.

3. Validators and ETags

The document is quite quiet on conditional GETs. Perhaps thats ok since it
things might "just work". However, the document does mention use of ETags in an
example. And as presented, the example is both invalid and raises some
questions.

The AI was very concerned about the **determinism of the response** (in contrast
to the determinism of the request). While RFC 9110 describes its the origin
servers prerogative to calculate ETags however they like, this doc might have to
do more. The AI raised the requirement in section 3.5 "Result sets always
include a timestamp indicating the expiry time of the entire result set." and
highlighted that results are signed via COSE (section 4.6) which may not be
byte-for-byte identical unless the server uses RFC 6979. I am not qualified to
comment authoritatively on these aspects of the payload. However, RFC 9110
section 8.8.1 does have text on this type of thing. The document might want to
consider spec'ing the use of weak validators if that's a better representation
of the information. SCIM appears to have had to do so. Strong validators based
on a hash of the content might cause all conditional requests to fail, which
would defeat the caching purposes of this protocol.

More specifically on ETags, the examples that use them are invalid - the origin
should be the ones generating them.

5. Freshness

This one is borderline minor. The document attempts to align CoSERV result
"embedded freshness" with HTTP freshness and provides a recommendation:

> the origin server MUST NOT set HTTP cache directives (e.g. Cache-Control:
> max-age, Expires) such that the freshness lifetime of the HTTP response
> exceeds the result set expiry timestamp contained within the CoSERV results.

That's good, but an origin might not set any Cache-Control directive in
responses. That could trigger an HTTP cache to use its own heuristics for
deciding on the cache freshness; see RFC 9111 section 4.2.2:

> Since origin servers do not always provide explicit expiration times, a cache
> MAY assign a heuristic expiration time when an explicit time is not specified,
> employing algorithms that use other field values (such as the Last-Modified
> time) to estimate a plausible expiration time. This specification does not
> provide specific algorithms, but it does impose worst-case constraints on
> their results.

The document might want to highlight the possibility for such an origin to
behave this way, even if there's not much that can be done to make genric HTTP
caches deal with it.

# Minor issues

6. Discovery content negotiation and response caching

It seems #94 was not properly resolved. There was a comment "I think we need to
say that servers MUST support both formats" but no text was actually added to do
it.

Leading on from that, the discovery document has two formats, JSON or CBOR. By
default, the responses for these objects is going to be cachable too. However,
the spec doesn't mention it. For scalability, I suspect you might want to
embrace it. If so, consider adding text about the `Vary: Accept` field in the
origin's response to ensure that a HTTP cache doesn't accidentally serve
a different type than a client might expect.

7. Accept looseness

The document levies some requirements on the Accept header:

> If the client presents any media type other than these two options in its HTTP
> Accept header, the implementation SHOULD respond with an HTTP 406 (Not
> Acceptable) status code

RFC 9110 section 12.4.1 has some text too:

>  For each of the content negotiation fields, a request that does not contain
>  the field implies that the sender has no preference on that dimension of
>  negotiation.

> If a content negotiation header field is present in a request and none of the
> available representations for the response can be considered acceptable
> according to it, the origin server can either honor the header field by
> sending a 406 (Not Acceptable) response or disregard the header field by
> treating the response as if it is not subject to content negotiation for that
> request header field. This does not imply, however, that the client will be
> able to use the representation.

I'm not sure if this spec is trying to be stricter than RFC 9110 or not. This
probably needs tightening up with a MUST, or just defer to RFC 9110 if it
doesn't matter much.

8. Error Content-Type broadness

The doc states:

> For error responses (4xx or 5xx status codes), the Content-Type header field
> MUST be application/concise-problem-details+cbor... containing [title,
> detail].

This is a bit broad because HTTP layered. the CoSERV app is running atop
lower-layer HTTP things, which could generate their own errors. It's more
correct to state something along the liens that a CoSERVER MUST send
application/concise-problem-details+cbor... content when returning error
responses (including the useful details like content-type and fields etc). That
accomodates for a client seeing any kind of error status with any content (or
none at all), that might be generated in an Internet deployment.

9. Rate limiting

There is an example about ratelimiting. I'm not sure it fits this document well.
Its possible that a layer beneath CoSERV could be implementing the rate
limiting, yet this example seems to imply its the CoSERV server?

The use of 429 overlaps a bit with issue 7. What should a client expect to do
with a rate limiting response, especially if it isn't the
application/concise-problem-details+cbor you're mandating at the CoSERV level.

The document might want to nix the example and instead describe the possibility
of rate limiting in the binding or security consideration sections. HTTP
ratelimiting is also evolving, using one very specific example might lead people
up the garden path.

If you want to keep this, the "MAY" is an issue and should be rephrased.

10. Truncated examples

The request examples have truncated URIs such as "/coserv/ogB4I3R...". Given how
important these are to the whole caching story it would be really useful to have
a fully worked value in the document somewhere. Even if the examples use a
short-hand for presentation.

11. Redirects

There is no definition of how redirects are to be handled. This seems
problematic given that there seems to be some expectation that the URI is
closely related the response content.

12. Inconsistent discovery responses

Section 6.1.2.3 has examples. The requests are to the same /.well-known endpoint
and vary only by the Accept header. However, the AI suggests the
"result-verification-key" doesn't match. This contrasts with other normative
text that states the responses should be equivalent apart from the
serialization.

13. Caching examples and time

The AI states the examples in 6.1.4.2 misuse HTTP fields. Its worth double
checking this once the ETag stuff is decided upon. RFC 9111 states

> When a stored response is used to satisfy a request without validation, a
> cache MUST generate an Age header field (Section 5.1), replacing any present
> in the response with a value equal to the stored response's current_age; see
> Section 4.2.3.

The example decrements values in Cache-Control and doesn't use Age. This is not
correct.

# Nits

14. The [HTTP] and [HTTP-CACHING] references seem to have been inverted :-)

15. Use URI consistently. Aside from base64url encoding, there seems to be a few
    "URLs" that have crept in.