Re: [TLS] DTLS 1.3 replay protection of post-handshake messages?

[John Mattsson <[e-mail]>]

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 <[e-mail]>
Date: Wednesday, 29 November 2023 at 06:02
To: Eric Rescorla <[e-mail]>, John Mattsson <[e-mail]>
Cc: [e-mail] <[e-mail]>
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=[e-mail]> 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 <[e-mail]> on behalf of John Mattsson <john.mattsson=[e-mail]>
>> *Date: *Tuesday, 28 November 2023 at 09:30
>> *To: *[e-mail] <[e-mail]>
>> *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 <[e-mail]> on behalf of John Mattsson <john.mattsson=[e-mail]>
>> *Date: *Friday, 24 November 2023 at 14:50
>> *To: *[e-mail] <[e-mail]>
>> *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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls