From 6b04ff72af1017ea5117d65f57263ce0144e1c14 Mon Sep 17 00:00:00 2001 From: chrysn Date: Wed, 23 Oct 2024 13:32:03 +0200 Subject: [PATCH] fixup! Apply Thomas' editorial suggestions. Co-authored-by: Thomas Fossati --- draft-bormann-core-corr-clar.md | 27 ++++++++++----------------- 1 file changed, 10 insertions(+), 17 deletions(-) diff --git a/draft-bormann-core-corr-clar.md b/draft-bormann-core-corr-clar.md index 1a6bd7b..9a405ab 100644 --- a/draft-bormann-core-corr-clar.md +++ b/draft-bormann-core-corr-clar.md @@ -497,15 +497,14 @@ PENDING. 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 topics but can be addressed using the same tools. +In those situations, a server still needs to maintain its security and amplification mitigation properties, +which are generally independent concerns but can be addressed using the same tools. A safe option is always to reject the initial request and request confirmation. The RECOMMENDED way to do that is 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); clients SHOULD act to the Echo option as specified in {{?RFC9175}}. -Tools specific to a security mechanism such as RRC ({{?I-D.ietf-tls-dtls-rrc}} may be used instead, -but their use may depend on successful negotiation. +Tools specific to a security protocol, such as RRC ({{?I-D.ietf-tls-dtls-rrc}}) in case of DTLS, may be used. However, their use may depend on successful negotiation. ### Amplification mitigation and return routability @@ -514,16 +513,12 @@ but the response does not exceed the request's size by a factor of 3 ({{Section 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. +This situation can happen at any time, especially after a prolonged period of quiescence, regardless of the security protocol. + +Verifying the client's address is not only crucial for mitigating amplification attacks ({{?I-D.irtf-t2trg-amplification-attacks}}), but also to avoid traffic misdirection. +{{Section 7 of ?I-D.ietf-tls-dtls-rrc}} describes options for how to use RRC messages to distinguish different cases. +A 4.01 response with Echo can perform some of the same functions, with the Echo value replacing the RRC cookie. However, it does not offer a way to distinguish between non-preferred and preferred paths. -Verifying the client's address is not only relevant for amplification attacks -(which addresses attacks described in {{?I-D.irtf-t2trg-amplification-attacks}}) -but also for traffic misdirection. -{{Section 7 of ?I-D.ietf-tls-dtls-rrc}} contains a menu of options how to use RRC messages to distinguish different cases. -An 4.01 response with Echo can perform some of the functions equivalently -(with the Echo value taking the place of the RRC cookie), -but does not provide a means to distinguish between non-preferred and preferred paths. Where that distinction matters, RRC provides the right tools to make it. @@ -544,11 +539,9 @@ 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). +Currently, this cannot happen in DTLS because 0-RTT Data is not allowed for CoAP (cf. {{Section 14 of ?I-D.ietf-uta-tls13-iot-profile-09}}). However, that may change if a future document defines a profile for using early data with CoAP. -Implementors of OSCORE beware answering potential replays is only safe from the CoAP application's point of view. +Implementers of OSCORE should be aware that 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.