Hello authors of -security-protocol-comparison, hello IOTOPS,
Just relaying to the list my comment from the session at IETF 116.
With reference to slide 6 of [1] showing Table 6 from [2], I think that
the overhead shown in the last row for "Group OSCORE pairwise response"
should be lower than what is in the current triple (11, 13, 14).
As per [3]: "The value of the 'kid' parameter in the 'unprotected' field
of response messages MUST be set to the Sender ID of the endpoint
transmitting the message, if the request was protected in group mode.
That is, unlike in [RFC8613], the 'kid' parameter is always present in
responses to a request that was protected in group mode."
Since you are considering a request protected in pairwise mode, the
response (irrespective of the mode use to protect it) is not required to
include the server's Sender ID. Then you would have a overhead triple
(11, 11, 11), i.e. the Sender ID size does not play a role in the
response overhead.
These are details that are admittedly worth clarifying in the text below
the comparison tables.
Best,
/Marco
P.S. Even if the Sender ID was included in the response, I would have
expected the triple to be (11, 12, 13) rather than (11, 13, 14), as
considering a Sender ID of 0, 1 and 2 bytes, respectively.
https://mailarchive.ietf.org/arch/msg/iotops/fxwOWBGTFb6pDzttkyYgGuLhdn8/
Hello authors of -security-protocol-comparison, hello IOTOPS,
Just relaying to the list my comment from the session at IETF 116.
With reference to slide 6 of [1] showing Table 6 from [2], I think that the overhead shown in the last row for "Group OSCORE pairwise response" should be lower than what is in the current triple (11, 13, 14).
As per [3]: "The value of the 'kid' parameter in the 'unprotected' field of response messages MUST be set to the Sender ID of the endpoint transmitting the message, if the request was protected in group mode. That is, unlike in [RFC8613], the 'kid' parameter is always present in responses to a request that was protected in group mode."
Since you are considering a request protected in pairwise mode, the response (irrespective of the mode use to protect it) is not required to include the server's Sender ID. Then you would have a overhead triple (11, 11, 11), i.e. the Sender ID size does not play a role in the response overhead.
These are details that are admittedly worth clarifying in the text below the comparison tables.
Best, /Marco
P.S. Even if the Sender ID was included in the response, I would have expected the triple to be (11, 12, 13) rather than (11, 13, 14), as considering a Sender ID of 0, 1 and 2 bytes, respectively.
[1] https://datatracker.ietf.org/meeting/116/materials/slides-116-iotops-comparison-of-coap-security-protocols-00.pdf
[2] https://datatracker.ietf.org/doc/html/draft-ietf-iotops-security-protocol-comparison-00#figure-6
[3] https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-17#section-4.2