From 7e19244802966d2fe3666f0a2fd2723685a2619c Mon Sep 17 00:00:00 2001 From: chrysn Date: Wed, 25 Sep 2024 21:50:15 +0200 Subject: [PATCH] Move amplification and 0RTT topic in from issue tracker This is a copy of https://github.com/core-wg/corrclar/issues/39#issue-2536406233 --- draft-bormann-core-corr-clar.md | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/draft-bormann-core-corr-clar.md b/draft-bormann-core-corr-clar.md index 6f5ea2b..3cd7504 100644 --- a/draft-bormann-core-corr-clar.md +++ b/draft-bormann-core-corr-clar.md @@ -488,6 +488,39 @@ issue include: * \\ ("Clarify/revise language around epochs in section 9.1.1 #9") +## RFC 7252-9.1/11.3: Handling outdated addresses and security contexts {#amp-0rtt} + +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. ## RFC 7252-12.3: Content-Format Registry {#ct}