On Tue, Sep 24, 2024, at 09:35, David Benjamin wrote: > On Tue, Sep 24, 2024, 12:12 Martin Thomson <m...@lowentropy.net> wrote: >> No DTLS implementation should treat unauthenticated packets as being fatal. >> Though perhaps that could be true prior to completing the handshake, the >> reasons for dying should still be somewhat limited. > > This is unavoidable, no? Suppose I sent you an unauthenticated ACK, or > part of a ClientHello/ServerHello with the wrong contents. Or maybe I > made you think that the server sent HelloRetryRquest or a non-existent > message as the first message. You'll update your internal state > accordingly and fail to complete the handshake, e.g. because the > transcript is wrong or you thought a packet was received but it wasn't.
I wasn't talking about something adversarial, but more accidental. I recognize that there will be some messages that will cause an endpoint to believe that they are talking to a valid implementation, but if the message you receive is of a completely new content type, why would that have an effect on the state machine. Maybe this isn't specified, so the result is that we get what we get, but it seems like a pretty brittle implementation if a random datagram causes the connection to be destroyed. (QUIC has some protection against an adversary who is unable to observe packets, but this is not a goal of DTLS.) _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
