search

core-wg / echo-request-tag

Other
0 stars 0 forks source link

concluded operation - dtls #78

Closed boaks closed 2 years ago

boaks commented 2 years ago

3.5.1 states

The client MUST NOT regard a block-wise request operation as concluded unless all of the messages the client has sent in the operation would be regarded as invalid by the server if they were replayed.

When security services are provided by DTLS, this can only be confirmed if there was no CoAP retransmission of the request, the request was responded to, and the server uses replay protection.

What should happen, if the client has retransmitted the request? Could that operation then be concluded at all?

chrysn commented 2 years ago

No, the operation can just never be concluded. In DTLS, for lack of an agreed-on replay window, Request-Tag values will (at least under some circumstances) start counting up just as tokens do.

When the security context is reestablished, all can start over from short identifiers again.

AIU there is some unclarity about how DTLS 1.3 features will behave with CoAP (like, what's the implicit Uri-Host in role reversal with session resumption, and something else was mentioned I don't remember). If at any point DTLS 1.3 and CoAP interactions are sharpened, it may well be that that document allows DTLS users to start reusing Token and Request-Tag values. Fortunately, both being under full control of the client, neither will pose any compatibility risk, as the server just uses both opaquely.

boaks commented 2 years ago

Thanks! That would have been also my conclusions.

(Knowing that's too late, and also not that important: my impression is, that the "helping information for implementations" is more: Though retransmission frequently happens and usually could not be prevented, using DTLS 1.2 even with replay protection makes it impossible to conclude operations except a fresh handshake is used.)