I agree that it would be good to require replay protection at this time. Perhaps we should just publish a short RFC requiring it.
-Ekr On Tue, Nov 28, 2023 at 3:00 PM John Mattsson <john.mattsson= 40ericsson....@dmarc.ietf.org> wrote: > 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> on behalf of John Mattsson > <john.mattsson=40ericsson....@dmarc.ietf.org> > *Date: *Tuesday, 28 November 2023 at 09:30 > *To: *TLS@ietf.org <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> on behalf of John Mattsson > <john.mattsson=40ericsson....@dmarc.ietf.org> > *Date: *Friday, 24 November 2023 at 14:50 > *To: *TLS@ietf.org <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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
