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
