0RTT and other cryptographically unconfirmed situations (DTLS CIDs, OSCORE B.1.2)

[chrysn]

CoAP based documents receive comments on how to correctly work with CIDs, eg. in https://mailarchive.ietf.org/arch/msg/core/Md4gV_0tUq7K6uyIwCjuRHSJOaA/. I'd prefer if those comments would not need to be addressed in those documents but once and for all in some CoAP update such as corr-clar.

The original comments were about DTLS CIDs, but we'd have the same with any zero-round-trip encrypted requests; for example, if an OSCORE server uses RFC8613 Appendix B.1.2 recovery, it's actually legitimate to send something else than a 4.01 Unauthorized along with the Echo option (but that needs some explanation as to when that's OK; DTLS RRCs hint at something similar on the DTLS side without going into CoAP specifics).

Proposed text (wherever that'll fit):

Established security contexts and established return addresses can become obsolete.
For example, this happens when a DTLS session is resumed via CIDs, when the client's IP address changes, or when the replay window of an OSCORE context is lost and recovered through the mechanism of [Appendix B.1.2 of RFC8613].
In those situations, a server still needs to maintain its security and and amplification mitigation properties,
which are generally independent but can be addressed using the same tools.

A safe option is always to reject the initial request and request confirmation,
either using CoAP's mechanism of sending a 4.01 (Unauthorized) response with an Echo option
(where a subsequent request with the same Echo value proves to the server that the destination was reachable)
or by using a more security mechanism specific tool such as RRC ({{?I-D.ietf-tls-dtls-rrc}}.

If it is not certain that the client is reachable on the request's sender address,
but the response does not exceed the request's size by a factor of 3 ({{Section 2.4 of RFC9175}}, item 3),
the server can answer the request.
It should still include an Echo value, whose presence in the next request serves to confirm the client's address.

If it is not certain that the request is not a replay,
but the request handler is safe or long-term idempotent
and there is no risk of metadata revealing data,
the server can answer the request.
Metadata that can reveal data are the size of the response
(which, in a replay situation, can give an active attacker additional data)
as well as any processing delays.
(There should be no observable side effects for safe or previously processed idempotent requests).
Assessing whether a resource is long-term idempotent is not always trivial, and it is prudent to err at the side of caution.
If nothing else, GET requests to constant resources,
such as queries to /.well-known/core,
can often be responded to safely on the CoAP layer even without any replay protection.

Implementors of OSCORE beware answering potential replays is only safe from the CoAP application's point of view.
As always, unless the sender sequence number of the request has just been removed from a correctly initialized replay window,
the response can not reuse the request's nonce, but needs to take an own sequence number from the server's space.

(I think this also picks up everything that is important from Section 3.1 of draft-amsuess-lwig-oscore-00, which doesn't really have a new home with LWIG shut down)

I'm taking the liberty to CC

• @miri64 (who is just addressing comments around this in DoC)
• @thomas-fossati (who made the comments and is also an author of RRC)
• @gselander, @emanjon, @rikard-sics and @marco-tiloca-sics (who are active around the OSCORE protection mechanisms)

[chrysn]

Changing as per today's interim:

• Add compatibility remark preferring Echo
• Add note that 0RTT is forbidden pending other document (along with general text on when things happen)

(And then this goes into a PR for better change tracking)

Established security contexts and established return addresses can become obsolete.
For example, this happens when a DTLS session is resumed via CIDs, when the client's IP address changes, or when the replay window of an OSCORE context is lost and recovered through the mechanism of [Appendix B.1.2 of RFC8613].
In those situations, a server still needs to maintain its security and and amplification mitigation properties,
which are generally independent but can be addressed using the same tools.

A safe option is always to reject the initial request and request confirmation,
eg. using CoAP's mechanism of sending a 4.01 (Unauthorized) response with an Echo option
(where a subsequent request with the same Echo value proves to the server that the destination was reachable).
It is RECOMMENDED to use the Echo mechanism for interoperability.
A more security mechanism specific tool such as RRC ({{?I-D.ietf-tls-dtls-rrc}} may be used instead,
but the peer may or may not support that extension.

If it is not certain that the client is reachable on the request's sender address,
but the response does not exceed the request's size by a factor of 3 ({{Section 2.4 of RFC9175}}, item 3),
the server can answer the request.
It should still include an Echo value, whose presence in the next request serves to confirm the client's address.
This situation can happen at any time in OSCORE,
or in DTLS after a CID based resumption.

If it is not certain that the request is not a replay,
but the request handler is safe or long-term idempotent
and there is no risk of metadata revealing data,
the server can answer the request.
Metadata that can reveal data are the size of the response
(which, in a replay situation, can give an active attacker additional data)
as well as any processing delays.
(There should be no observable side effects for safe or previously processed idempotent requests).
Assessing whether a resource is long-term idempotent is not always trivial, and it is prudent to err at the side of caution.
If nothing else, GET requests to constant resources,
such as queries to /.well-known/core,
can often be responded to safely on the CoAP layer even without any replay protection.
This situation can happen in OSCORE after a partial loss of context.
It can currently not happen in DTLS because 0-RTT Data is not allowed for CoAP (cf. {{Section 14 of ?I-D.ietf-uta-tls13-iot-profile-09}})
at the time of writing
(but that may change with a future document).

Implementors of OSCORE beware answering potential replays is only safe from the CoAP application's point of view.
As always, unless the sender sequence number of the request has just been removed from a correctly initialized replay window,
the response can not reuse the request's nonce, but needs to take an own sequence number from the server's space.

[chrysn]

Also per today's interim, checking we're not missing anything:

• RRC can do "are you still there". Echo doesn't do that, but we have CoAP pings for that. Don't think this needs mentioning here.
• RRC is negotiated, Echo is not. That's fine because Echo can be used in a fine-grained way: If the server really needs the confirmation, it'll do a 4.01 with Echo – "sorry, no can do". If the server prefers confirmation but can still answer, Echo on a response is not critical, and things can continue until either the server needs the Echo (at which point, again, sorry but there's no other way than to fail) or the server has seen confirmation in a different way.
• RRC concerns itself with off-path packet forwarding in section 6.2 in its enhanced path validation algorithm. If our match-boxing allows it, the strategy can be ported (and will get a mention); if not, it's something CoAP can't do the same way (TBD in the upcoming PR).
  • With OSCORE, that kind of trick is certainly not match-boxable: The response needs to travel the same path as the request over the underlying unprotected CoAP layer. Then again, OSCORE is specifically designed to allow untrusted intermediaries, so that's not supposed to be there.

[thomas-fossati]

cc @boaks