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.
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
