tlswg / dtls13-spec

Repo for DTLS 1.3
32 stars 25 forks source link

Establishing New Associations with Existing Parameters - SHOULD / please add description of the alternatives #251

Closed boaks closed 3 years ago

boaks commented 3 years ago

Establishing New Associations with Existing Parameters

In cases where a server believes it has an existing association on a given host/port quartet and it receives an epoch=0 ClientHello, it SHOULD proceed with a new handshake but MUST NOT destroy the existing association until the client has demonstrated reachability either by completing a cookie exchange or by completing a complete handshake including delivering a verifiable Finished message.

(The same statement is also used in DTLS 1.2, RFC6347 4.2.8. Establishing New Associations with Existing Parameters.)

Basically it's about the SHOULD, because in a naive interpretation of that opens also alternative ways to go. Otherwise it would be a MUST. Therefore I would enjoy it, if some words about that alternatives, e.g. environments or other motivation, could be added.

In my experience with the IoT usage of DTLS 1.2, it seems, that RFC5246 - 7.2.1. Closure Alert is used as alternative. But that results in some unreliability (e.g. RIOT, down the comments, about the motivation to use close).

Reading #248 and the "Generally, I think that's out of scope at this time.", I somehow think, this is the same for this issue. Maybe, if it's more the rough ideas behind than the details of the alternative, it 's not that disruptive (but more helpful than using a Closure Alert).

boaks commented 3 years ago

I guess, it's too late.