Potential things to add to future update

[emanjon]

• Change "master" to "main"

• Encryption of sequence numbers. This idea comes from QUIC and is used also in DTLS 1.3. It provides improves privacy when the sequence number helps an attacker track an endpoint. Quite uncertain if encrypting sequence numbers improves privacy in OSCORE as Token and Sender ID are in cleartext. OSCORE already removes sequence number for most responses.

• No sequence number for certain transport like TCP. This is how TLS 1.3 works. Unclear how big use case this is.

• Only send sequence number mod N. This is how SRTP and DTLS 1.3 works. OSCORE could e.g. use mod 24, mod 256, or mod 2^16. This could provide savings but is incompatible with mechanisms to recover from reboot.

• Padding to hide length of the encrypted data or send dummy packets. This idea comes from ESP in IPsec where it is called traffic flow confidentiality and is now part of (D)TLS 1.3, QUIC, and DTLS 1.2 with connection IDs.

• Allowing multiple kid (Sender ID, Recipient ID) and kid context per connection. This is allowed by QUIC.

• kid (Sender ID, Recipient ID) and kid context update mechanism to mitigate that an attacker is able to correlate different paths. Such mechanism was introduced in QUIC and is also part of DTLS 1.3. If done, update should likely be done at the same time the sequence number is reset or combined with sequence number encryptioin.

• Discussion on lower layers. OSCORE does not discuss address updates. I assume it can be assumed that the server send responses to the address it received the request from. A MITM might change the address of an observe registration and use that as an DDoS attack.

[chrysn]

As for encryption of the sequence number, I don't see much benefit given that the key ID is still around. (Token and MID might be hidden by a proxy).

I would see value if we'd manage to encrypt the whole OSCORE option (except for the first bit that'd indicate it's encrypted), but that'd depend on all clients to learn a secret the sever shares with all its OSCORE clients for a limited time. However, I'm doubtful whether the added complexity (especially around "how to reliably roll over" and "how to prevent downgrades where an intermediary pretends that the server couldn't decrypt the encrypted OSCORE option") warrants the added privacy, given that a proxy (that hides tokens / MIDs, otherwise this is all kind of for nothing) could also establish an OSCORE tunnel with the server.

[chrysn]

Also, comparing to DTLS 1.3, whenever OSCORE does its equivalent of CID changes, sequence numbers reset anyway. (Tracking across CID changes is what motivates sequence number encryption in draft-ietf-tls-dtls13-43 Section 11).

In general, I appreciate collecting these things for further updates, and trust that we'll jointly do very careful vetting of anything that increases implementation complexity.

[chrysn]

There was related discussion today in EDHOC on not having visible identifiers, where the visibility of identifiers came up again.

[emanjon]

Great that you are commenting Christian. I added padding and identity update mechanism to the list above. I think kids need to be visible. The mitigation would like be a kid update mechanism similar to QUIC and DTLS 1.3

I fully agree with you. The list is not meant to be things that should be done. It is a list of potential things that we might do after careful vetting any benefits against increased implementation complexity.

We should maybe discuss to add a identity update mechanism to the rekeying mechanism document "Key Update for OSCORE (KUDOS)"

[emanjon]

One thing that could be added IF there ever is an RFC8613bis is: Discussion on lower layers. OSCORE does not discuss address updates. I assume it can be assumed that the server send responses to the address it received the request from. A MITM might change the address of an observe registration and use that as an DDoS attack. Not sure how practical the attack is but DTLS 1.3 writes that it is a concern.

https://github.com/EricssonResearch/coap-actuators/blob/master/draft-mattsson-t2trg-amplification-attacks.md

[chrysn]

Based on the impact on cacheable OSCORE (see its issue 19), I suggest that any future update revisit the classification of the Observe option; outer-only would solve a few problems, and does save a byte here and there.