[core] No-Response option and OSCORE

[Francesca Palombini <[e-mail]>]

Hi all,

In order to add the processing of the No-Response in the OSCORE document, as requested by a few people, I was reading RFC7967 and previous conversations [1] in the mailing list, regarding proxies behavior when using No-Response.

RFC7967 specifies No-Response as an Unsafe-to-forward option (and therefore not part of the cache key). Because of that, proxies are allowed to legitimately discard this option. Moreover, even when the server receives this option, it might legitimately decide to respond to the request anyway.

We have three choices as of OSCORE processing: we can treat the No-Response as an unprotected only option (outer), as an encrypted only (inner), or as a both encrypted/inner (to the server) and unprotected/outer (for any intermediaries) option.

This is a question for No-Response users, such as the authors of RFC7967 and Esko:
We assume having an inner No-Response is convenient, since we are guaranteed that it reaches the server unchanged. Is this assumption correct, does your use case profits from a protected client-to-server No-Response option?

To anybody, particularly the authors of RFC7967:
We think it is necessary to send the option as an outer option too, to keep the functionality of No-Response-aware proxies. This means that we should allow inner and outer No-Response at the same time (where we recommend the outer value to be the same as the inner value). The only problem is, since No-Response is Unsafe to forward, No-Responses-unaware proxies might be waiting on the responses while the server, having received the inner No-Response might not respond. Is this a reasonable tradeoff?

Finally, I have a question non concerning OSCORE but [1] and the document in general, for the authors and for Klaus, on anyone that has an opinion. My question concerns the decision to make this option Unsafe-to-forward. In my opinion, to deal with cacheability, it would have been enough to make the option Safe-to-forward, and part of the cache-key.

In [1] Klaus said:
If a server returns a 4.04 response (or any other cacheable error
response) with Max-Age != 0, then a cache will return that response as long as Max-Age has not elapsed instead of making a request towards the origin server. So the caching of error responses protects a server a bit from clients repeatedly triggering the same error. The No-Response option destroys this protection. To limit the damage, I would say that intermediaries MUST NOT include the No-Response option in their requests.

Question: Having No-Response safe-to-forward and part of the cache key would work, since the requests would hit the cache in that case, right? Why was the option specifically defined to unsafe-to-forward? I'd like to know because if I have missed something in the proxy processing I could get the OSCORE processing wrong.

Thanks,
Francesca


[1] http://mailarchive.ietf.org/arch/msg/core/X00OZOjL8mcnyzZy6dSqlGO2LuQ