On Tue, Sep 24, 2024, 12:12 Martin Thomson <m...@lowentropy.net> wrote:
> On Thu, Sep 12, 2024, at 13:31, David Benjamin wrote:
> > 1. If a DTLS 1.2 (i.e. does not implement RFC 9147 at all)
> > implementation receives an ACK record for whatever reason, what
> > happens? This decision we don't get to change. Rather, it is a design
> > constraint. Both OpenSSL and BoringSSL treat unexpected record types as
> > a fatal error. I haven't checked other implementations. So I think we
> > must take as a constraint that you cannot send an ACK unless you know
> > the peer is 1.3-capable.
>
> This is tangential, but I find this claim about {Open|Boring}SSL to be a
> bit troubling, if true.
>
> 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.
If the attacker can manipulate the transport for a given connection, they
can cause the connection to fail. That's true in either TLS or DTLS. Of
course, if they can break the integrity or confidentiality of the
connection, that's a problem. Or if one connection can cause *another*
connection to fail by using disproportionate global resources. But things
we do in this working group can't really guarantee availability in the face
of the underlying transport not working at all.
David
>
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
