>I believe that the reason this exists is that some higher-layer protocols have >their own replay protection, such that as long as the datagram is authentic, >it is safe. I agree that you theoretically do that. But I don’t see the problem in these cases. Replay protection is almost free. I do understand the use case in RFC 6083 where DTLS is sent on top of SCTP and having DTLS replay protection turned on cause problems. But I also think that DTLS over SCTP is not a good design.
>NSS has no means to disable replay protection and I see no reason to add that >means. That seems like the right approach to me. Cheers, John From: TLS <tls-boun...@ietf.org> on behalf of Martin Thomson <m...@lowentropy.net> Date: Tuesday, 28 November 2023 at 23:11 To: tls@ietf.org <tls@ietf.org> Subject: Re: [TLS] DTLS 1.3 replay protection of post-handshake messages? On Tue, Nov 28, 2023, at 19:29, John Mattsson wrote: > I would strongly recommend all DTLS 1.3 libraries to completely remove > the option to disable replay protection. I believe that the reason this exists is that some higher-layer protocols have their own replay protection, such that as long as the datagram is authentic, it is safe. However, I agree that if we are sending handshake messages that affect DTLS state, it is probably not good to have the DTLS layer fail to provide that protection. I believe that you can operate DTLS 1.3 without post-handshake handshake/control messages, in which case you might manage to avoid exposure. NSS has no means to disable replay protection and I see no reason to add that means. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
