Hi John, the reason for not having replay protection for the application data is not because there is no replay protection at all but rather that there are applications that provide replay protection instead of using the lower layer. Hence, the scenario you present below is likely not going to be applicable because the replay detection will happen at the higher layer.
Ciao Hannes Von: TLS <tls-boun...@ietf.org> Im Auftrag von John Mattsson Gesendet: Mittwoch, 29. November 2023 00:00 An: TLS@ietf.org Betreff: Re: [TLS] DTLS 1.3 replay protection of post-handshake messages? Hi, Lack of replay also enables tracking of client and server. If the client or server is a device moving together with a person this enables tracking of the person. An attacker can store a message from one location and then replay it to the client or server in another location. If the client or server accept the replayed message, the attacker knows that the device in the two locations are one and the same. It is best practice to assume that an attacker can always detect if a message was accepted. If the client or server send a response to the replayed message (like a replayed client authentication request) this is trivial. This is different from the attack described in Section C.4 "Client and Server Tracking Prevention" of RFC8446bis, which describes the client reusing a ticket. A network attacker mounting a replay attack are described in Section 8 of RFC8446bis. I think a sentence or two should be added to Section C.4 to describe that a network attacker mounting a replay attack can be used for server tracking and that the mitigations in Section 8 help. https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis/ Cheers, John Preuß Mattsson From: TLS <tls-boun...@ietf.org<mailto:tls-boun...@ietf.org>> on behalf of John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org<mailto:john.mattsson=40ericsson....@dmarc.ietf.org>> Date: Tuesday, 28 November 2023 at 09:30 To: TLS@ietf.org<mailto:TLS@ietf.org> <tls@ietf.org<mailto:tls@ietf.org>> Subject: Re: [TLS] DTLS 1.3 replay protection of post-handshake messages? Hi, Reading RFC 9147 (DTLS 1.3) I cannot find any other interpretation than that replay protection may be disabled for all records. This is not a problem for the initial lock-step handshake, alerts, KeyUpdate, and ACKs. It seems to be a major problem for NewSessionTicket, NewConnectionId, RequestConnectionId, and Post-handshake client authentication as the lack of replay protection might significantly affect availability. It seems to me that DTLS 1.3 forgot to update replay protection based on the new post-handshake messages. Let me know if I miss something. It is a bit surprising that DTLS 1.3 published in 2022 allows the application to turn off replay protection at all. This very far from current best practice for security protocols. There are very good reasons why Datagram QUIC mandates replay protection and why TLS 1.3 has several pages discussing security considerations for 0-RTT data, which lacks replay protection. In general, turning off replay protection (even just for application data) might lead to loss of confidentiality, integrity, and availability, i.e., the whole CIA triad. Applications cannot be expected to understand the severe consequences of not having replay protection or understand how to fix it on the application layer. I also don't see any need for turning off replay protection except RFC 6083 which is a bit of a special case, and which turned out to have replay issues. https://datatracker.ietf.org/meeting/115/materials/slides-115-tsvwg-sctp-auth-security-issues-00 I would strongly recommend all DTLS 1.3 libraries to completely remove the option to disable replay protection. An easy fix for the post-handshake messages is to "clarify" that replay protection must not be turned off for anything else than application data. I you agree I can submit an "erratum" for RFC 9147. But this does not solve the general issue that turning off replay protection would be a major security problem in almost all applications. Cheers, John Preuß Mattsson From: TLS <tls-boun...@ietf.org<mailto:tls-boun...@ietf.org>> on behalf of John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org<mailto:john.mattsson=40ericsson....@dmarc.ietf.org>> Date: Friday, 24 November 2023 at 14:50 To: TLS@ietf.org<mailto:TLS@ietf.org> <tls@ietf.org<mailto:tls@ietf.org>> Subject: [TLS] DTLS 1.3 replay protection of post-handshake messages? Hi, How does replay protection of Post-handshake messages work in DTLS 1.3 if the per-record replay-protection mechanism is turned off? 1. Is the post-handshake messages replay protected in some other way, which I miss? 2. Should RFC 9147 state that the per-record replay-protection mechanism can only be turned off for application data? (I could not find anything in RFC 9147 stating something like this). (things like post-handshake authentication need replay protection in some way) Cheers, John Preuß Mattsson
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
