From 7297e9480f56c18d3e01fc847021a621a057ba04 Mon Sep 17 00:00:00 2001 From: ID Bot Date: Thu, 17 Oct 2024 08:09:53 +0000 Subject: [PATCH] Script updating gh-pages from 7a21ada. [ci skip] --- draft-ietf-core-groupcomm-proxy.html | 2 +- draft-ietf-core-groupcomm-proxy.txt | 18 ++++++++++-------- 2 files changed, 11 insertions(+), 9 deletions(-) diff --git a/draft-ietf-core-groupcomm-proxy.html b/draft-ietf-core-groupcomm-proxy.html index d644d49..8cd164a 100644 --- a/draft-ietf-core-groupcomm-proxy.html +++ b/draft-ietf-core-groupcomm-proxy.html @@ -2740,7 +2740,7 @@

The Group-ETag Option is of class U for OSCORE [RFC8613]. Hence, also when Group OSCORE is used between the client and the servers [I-D.ietf-core-oscore-groupcomm], a proxy is able to access the option value and use it to possibly perform response revalidation at its cache entries associated with the servers in the CoAP group, as well as to remove the option altogether before forwarding the group request to the servers. When a chain of proxies is used (see Section 8), this also allows each proxy but the last one in the chain to update the option value, to possibly ask the next hop towards the origin servers to perform response revalidation at its cache entries.

The security association between the client and the proxy MUST provide message integrity, so that further intermediaries between the two as well as on-path active adversaries are not able to undetectably remove the option or alter its content, before the group request reaches the proxy.

Removing the option would result in the proxy not performing response revalidation at its cache entries associated with the servers in the CoAP group, even though that was what the client asked for.

-

Altering the option content in a group request would result in the proxy failing the response revalidation and hence not replying with a single 2.03 (Valid) response, but instead with multiple 2.05 (Content) responses conveying the full resource representations from its cache entries. Instead, altering the option content in a 2.03 (Valid) or 2.05 (Content) response would result in the client wrongly believing that the already stored or the just received representation, respectively, is also the current one, as per the entity value of the tampered Group-ETag Option.

+

Altering the option content in a group request would result in the proxy performing response revalidation based on different entity-tag values from those actually specified by the client. Consequently, the proxy would erroneously reply with multiple 2.05 (Content) responses conveying the full resource representations from its cache entries instead of with a single 2.03 (Valid) response, or vice versa. Instead, altering the option content in a 2.03 (Valid) or 2.05 (Content) response would result in the client wrongly believing that the already stored or the just received representation, respectively, is also the current one, as per the entity value of the tampered Group-ETag Option.

The security association between the client and the proxy SHOULD also provide message confidentiality. Otherwise, any further intermediaries between the two as well as any on-path passive adversaries would be able to access the option content, and thus learn the rate and pattern according to which the group resource in question changes over time, as inferable from the entity values read over time.

When the client protects the unicast request sent to the proxy using OSCORE (see [I-D.ietf-core-oscore-capable-proxies]) and/or (D)TLS, both message integrity and message confidentiality are achieved in the leg between the client and the proxy.

The same considerations above about security associations apply when a chain of proxies is used (see Section 8), with each proxy but the last one in the chain acting as client with the next hop towards the origin servers.

diff --git a/draft-ietf-core-groupcomm-proxy.txt b/draft-ietf-core-groupcomm-proxy.txt index 6003cfc..2fd6034 100644 --- a/draft-ietf-core-groupcomm-proxy.txt +++ b/draft-ietf-core-groupcomm-proxy.txt @@ -2102,14 +2102,16 @@ Table of Contents CoAP group, even though that was what the client asked for. Altering the option content in a group request would result in the - proxy failing the response revalidation and hence not replying with a - single 2.03 (Valid) response, but instead with multiple 2.05 - (Content) responses conveying the full resource representations from - its cache entries. Instead, altering the option content in a 2.03 - (Valid) or 2.05 (Content) response would result in the client wrongly - believing that the already stored or the just received - representation, respectively, is also the current one, as per the - entity value of the tampered Group-ETag Option. + proxy performing response revalidation based on different entity-tag + values from those actually specified by the client. Consequently, + the proxy would erroneously reply with multiple 2.05 (Content) + responses conveying the full resource representations from its cache + entries instead of with a single 2.03 (Valid) response, or vice + versa. Instead, altering the option content in a 2.03 (Valid) or + 2.05 (Content) response would result in the client wrongly believing + that the already stored or the just received representation, + respectively, is also the current one, as per the entity value of the + tampered Group-ETag Option. The security association between the client and the proxy SHOULD also provide message confidentiality. Otherwise, any further