Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Amplification and 0-RTT #40

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Amplification and 0-RTT #40

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
7e19244
Move amplification and 0RTT topic in from issue tracker
chrysn Sep 25, 2024
03e069e
Update amplification/0RTT
chrysn Sep 25, 2024
5f38ab3
amplification/0rtt: Reword, structure
chrysn Sep 25, 2024
05d250b
amplification/0rtt: Point out feature differences with RRC
chrysn Sep 25, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 33 additions & 0 deletions draft-bormann-core-corr-clar.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -488,6 +488,39 @@ issue include:
* <https://github.com/core-wg/corrclar/issues/9>\\
("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].
Comment on lines +498 to +499
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the term "resumed" is in my opinion misleading. Maybe "continued" is better?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

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,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How can the server achieve "certainty that the request is not a replay?"

Copy link

@boaks boaks Oct 1, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can't => (see comment)

but the request handler is safe or long-term idempotent
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the meaning of "long-term idempotent"? I have never heard of it :-)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but if the same request applied later ("long-term") does the same ("idempotent"), it's not required, that the server know about the replay attack.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a vague field and will need better terminology.

In 7252 (or HTTP below it), idempotent requests are requests that, once executed, have no further effect.

But the term does not distinguish between whether that's just if they're executed right after another or whether anything else may happen between their executions (maybe from the same client / user, maybe from a different one). As it is used in 7252, it's about duplication, so there it's about whether a request is processed again within EXCHANGE_LIFETIME, but that doesn't tell much about what else might have changed.

It may well be that the best course of action is to just talk about safe requests, and leave idempotency at most to a footnote.

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.
Comment on lines +536 to +538
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am struggling with the semantics of this paragraph.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

(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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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.
Comment on lines +552 to +553
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • "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"


## RFC 7252-12.3: Content-Format Registry {#ct}

Expand Down