On Tue, Sep 24, 2024, 13:03 Martin Thomson <m...@lowentropy.net> wrote:
> > > 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.) > Sure. I don't have any feelings about dropping vs erroring on unexpected content types. (On our end, this behavior was just carried over from OpenSSL and we never had any particular cares to change it either way.) But this behavior isn't related to DoS or packet authentication because one can already unavoidably do much more with the ability to inject unauthenticated packets. Once we're taking about *accidentally* getting garbage packets in, authentication is just a fancy checksum. Though I don't think believing it talking to a valid implementation is quite the right characterization. If there isn't a valid implementation on the other side, it can't matter if you fail on the record because there's no one to handshake with anyway! Failing on the record is only a concern if there *is* a valid peer, but somehow you processed a packet thinking it was from the peer's DTLS code, but it wasn't. If that packet was injected maliciously, it can easily interfere with your connection to the peer at the plaintext stage of the connection, content type rejection or no. If it was injected accidentally, well, I guess now we need to reason about the probability distribution of accidents and whether it's likely to have a valid plaintext header (version and length prefix) but wrong content type. Given the 1.3 record header dispatch, it's probably natural now to just toss the record, but I don't think it's a huge deal either way. David >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
