Amplification and 0-RTT #40
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This includes the changes from core-wg#39 (comment) Closes: core-wg#39
|
We had an action item in today's interim to inform the RRC authors of what we're doing, but thanks, you already took care of that yourselves :-) |
Comment on lines
+498
to
+499
| 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]. |
There was a problem hiding this comment.
Fix ref typo.
Also, the TLS purist might turn his nose up at the use of resume - session resumption completely separate from CID.
Also, I suggest splitting the two conditions and pairing them with their respective examples.
Suggested change
| 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]. | |
| Established security contexts can become obsolete. | |
| For example, when the replay window of an OSCORE context is lost and recovered through the mechanism described in {{Appendix B.1.2 of RFC8613}}. | |
| Established return addresses can become obsolete. | |
| For example, this happens when the use of Connection ID (CID) {{RFC9146}} allows the DTLS session to survive the client's IP address change. |
There was a problem hiding this comment.
Yes, the term "resumed" is in my opinion misleading. Maybe "continued" is better?
There was a problem hiding this comment.
To be frank I have little knowledge of either session resumptions and CID. My guess is that both can lead to 0RTT situations. If so, is there a general term covering both?
Comment on lines
+500
to
+501
| 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. |
There was a problem hiding this comment.
remove duplicate "and"
s/topic/concern/
Suggested change
| 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. |
Comment on lines
+507
to
+508
| 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. |
There was a problem hiding this comment.
Fix missing parenthesis.
Also s/mechanism/protocol/
Also, split long sentence in two.
Suggested change
| 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. |
Comment on lines
+517
to
+518
| This situation can happen at any time in OSCORE, | ||
| or in DTLS after a CID based resumption. |
There was a problem hiding this comment.
Suggested change
| 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. |
Comment on lines
+520
to
+522
| 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. |
There was a problem hiding this comment.
Suggested change
| 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. | |
| 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. |
Comment on lines
+536
to
+538
| 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 was a problem hiding this comment.
I am struggling with the semantics of this paragraph.
There was a problem hiding this comment.
I guess, that means, a server "can answer", if there no other security issues, e.g. the size of the response or the time to process the request, which may be considered to be used as "metadata" for an attack.
| 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. |
There was a problem hiding this comment.
It's unclear what "This situation" refers to.
Comment on lines
+547
to
+549
| 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). |
There was a problem hiding this comment.
Suggested change
| 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. |
| 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. |
There was a problem hiding this comment.
grammar
Suggested change
| 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. |
Comment on lines
+552
to
+553
| 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. |
There was a problem hiding this comment.
- "As always" can be removed.
- "sender sequence number of the request" => "request sequence number"
- Why is it important to qualify the anti-reply window as "correctly initialized"?
- "an own sequence number" => "its sequence number"
- spurious comma "nonce, but"
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds text I suggested in #39 to close it.
Compared to the text discussed there, it also takes up the TBD item of covering the advanced return routability strategies (mainly by saying "apply what you can or just use RRC"). Unlike envisioned there I did not say that that doesn't work on OSCORE, because as long as it's all about flipping NATs and attacks sending the response through the old address will work, but I don't want to waste time on IPv4 stuff, and it kind of feels off to counter an attack by doing layering violations (sending the OSCORE response to the old address is one, as it affects the underlying CoAP layer). If there is a need to ensure that there are no proxies on an OSCORE hop (or that all are known), I'd rather discuss how to do that once-and-for-all than by probing around at address change time.
Slightly differently from the interim discussion the text is not marked as "this will go away", because it's more offering criteria for when a 0RTT response is good than saying that it can be done over DTLS (so it now only contains an unspec reference to whichever document will say that it is allowed, and that document can then defer to corrclar for criteria or take the text, depending on preferences and timelines).
CC'ing @boaks as per @thomas-fossati's suggestion