Amplification and 0-RTT

[chrysn]

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

[chrysn]

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 :-)

[thomas-fossati]

Thanks! I've left a few editorial comments and a request for a couple of clarifications in the anti-reply section.

[thomas-fossati]

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.

[boaks]

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

[chrysn]

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?

[chrysn]

Says "continued" now; are those different mechanisms?

[boaks]

Not sure, if I get the question:
A DTLS 1.2 session resumption is a sequence of messages. Before DTLS 1.2 CID, this was a common approach to continue encryption, if a peer assumes an ip-address change. But it comes with overhead.
DTLS 1.2 CID is a general solution for such address changes, the overhead there is mainly the bytes for the CID.

[thomas-fossati]

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

[chrysn]

I think there is value in the "As always" as it emphasizes that we're not making new rules here.

"request sequence number" and "its sequence number" are kind of right, but given that not every OSCORE message even carries a sequence number (or when it does not carry one, there is an implied one from another number space), I'll try to find more a precise rephrasing.

[chrysn]

I've changed the sentence a bit.

Are you sure about the comma? The sentence parts on both sides have full verbs, which IIRC is the criterion for when to use a comma in situations such as this.

[chrysn]

ToDo on this from yesterday's interim: Restructure so that it becomes apparent that

• There are two different concerns that can come up in different situations (although the term "continuity" may apply to both, gotta check notes)
• They are explained together because
  • it is common that they do coincide (after long time, the client may have changed address, the server may have discarded state, possibly including the client's address)
  • the same mechanism can be used to counteract both issues
  • counteracting them can be done in a single round tip

[boaks]

it is common that they do coincide (after long time, the client may have changed address, the server may have discarded state, possibly including the client's address)

I guess the point will be, that this may apply when using a server with a "general configuration". But if the operator are aware of the applications specific communication pattern (long quiet phases to save energy) then it should be possible to configure the server with larger timeouts and so the only thing, which is changing is the client's ip-address and nothing will be lost.

counteracting them can be done in a single round tip

Still not sure, if I get that. DTLS 1.2 CID doesn't need a round trip. There is nothing required, because the address change is considered and doesn't require more to do. From the perspective of CoAP this is a simple request from one endpoint to the other. Just instead of a "changing ip-address" it uses the "static CID" to identify that endpoint, that's it.

[chrysn]

general configuration

Sure: A highly capable server may never run into the situation of having lost OSCORE context. The point here is more about justifying why those would treated together in the first place, and based on your comment I'll make sure to phrase that in a way that makes it clear that this is a merely a general expectaton.

CID doesn't need a round trip

The only point where the round trip dance is fundamentally required is when (independently of any OSCORE state loss) the client address changed and the server needs to send more than 3x the data the client requested. I have the full CID document on my reading list, but as far as I understand it so far, I don't see how CID behaves differently. Otherwise, any captured packet could be used either as an amplification vector, or its injection from a different address denies the continuation to the legitimate client.

All other situations where the round trip is needed merely occur if some simplifications or optimizations are used (for example because the server needs to keep its flash writes low).

[boaks]

send more than 3x the data the client requested.

Ah, OK, that's RRC, which is in the (review?) pipe of the tls working group.

[cabo]

A couple passages that are hard to understand.

[cabo]

"unavailable when specified" -- please explain.

[cabo]

codes == request codes (methods)?

[cabo]

... can only determined to be safe...?

[chrysn]

As requested in the last interim, I've rewritten this section to focus more on why this is needed, what it does and what the commonalities are. It's a large rewrite, diff-wise, but the fact that Carsten's latest 3 comments all touched on text that is still around makes me more confident that I didn't completely turn it around.

[chrysn]

@cabo, @boaks, @thomas-fossati, is the updated text fine with you?