In today's meeting, we agreed to do 9147-bis, so I think we should put this rule in there even if we also do a separate draft.
-Ekr On Thu, Nov 7, 2024 at 11:10 PM John Mattsson <john.matts...@ericsson.com> wrote: > > > Hi Eric, Martin, > > > > You suggested writing an RFC require replay protection in DTLS 1.3. I was > just planning to start writing such a -00 draft but now I see there is “DTLS > Clarifications - David Benjamin (15 min)” on the agenda. If that means > RFC9147bis, it might be better to have it there. But based on Martin > comments, I separate draft might have value anyway. > > > > > I agree that it would be good to require replay protection at this > > time. Perhaps we should just publish a short RFC requiring it. > > > > Cheers, > > John > > > > *From: *John Mattsson <john.matts...@ericsson.com> > *Date: *Thursday, 28 December 2023 at 13:47 > *To: *Martin Thomson <m...@lowentropy.net>, Eric Rescorla <e...@rtfm.com> > *Cc: *tls@ietf.org <tls@ietf.org> > *Subject: *Re: [TLS] DTLS 1.3 replay protection of post-handshake > messages? > > On Wed, Nov 29, 2023, at 11:21, Eric Rescorla wrote: > > I agree that it would be good to require replay protection at this > > time. Perhaps we should just publish a short RFC requiring it. > > I think that is a good idea and I would be happy to help with such an RFC. > Either one mandating DTLS replay protection or one mandating replay > protection at some layer. > > I think it would maybe make most sense to mandate DTLS replay protection. > Applications wanting to turn off DTLS replay protection should be required > to register an extension. > > > > I made a PR to RFC8446bis that shortly describes that 0-RTT replay can be > used for server tracking. > > https://github.com/tlswg/tls13-spec/pull/1334/files > > > > Cheers, > > John Preuß Mattsson > > > > *From: *Martin Thomson <m...@lowentropy.net> > *Date: *Wednesday, 29 November 2023 at 06:02 > *To: *Eric Rescorla <e...@rtfm.com>, John Mattsson < > john.matts...@ericsson.com> > *Cc: *tls@ietf.org <tls@ietf.org> > *Subject: *Re: [TLS] DTLS 1.3 replay protection of post-handshake > messages? > > One thing that I observed when we were doing QUIC was that the canonical > reference for how to do this sort of anti-replay is a section that is > buried deep in an IPsec RFC. Perhaps that short RFC is an opportunity to > also document the process in a way that can be a reference to other > documents. (That's a slightly longer RFC, but still fairly short; Section > 3.4.3 of RFC 4303 is just two pages in the old measure.) > > On Wed, Nov 29, 2023, at 11:21, Eric Rescorla wrote: > > 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 >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
