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

[John Mattsson]

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  on behalf of John Mattsson 

Date: Friday, 24 November 2023 at 14:50
To: 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

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

[Martin Thomson]

On Tue, Nov 28, 2023, at 19:29, John Mattsson wrote:
> I would strongly recommend all DTLS 1.3 libraries to completely remove 
> the option to disable replay protection.

I believe that the reason this exists is that some higher-layer protocols have 
their own replay protection, such that as long as the datagram is authentic, it 
is safe.  However, I agree that if we are sending handshake messages that 
affect DTLS state, it is probably not good to have the DTLS layer fail to 
provide that protection.  I believe that you can operate DTLS 1.3 without 
post-handshake handshake/control messages, in which case you might manage to 
avoid exposure.

NSS has no means to disable replay protection and I see no reason to add that 
means.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[John Mattsson]

>I believe that the reason this exists is that some higher-layer protocols have 
>their own replay protection, such that as long as the datagram is authentic, 
>it is safe.
I agree that you theoretically do that. But I don’t see the problem in these 
cases. Replay protection is almost free. I do understand the use case in RFC 
6083 where DTLS is sent on top of SCTP and having DTLS replay protection turned 
on cause problems. But I also think that DTLS over SCTP is not a good design.

>NSS has no means to disable replay protection and I see no reason to add that 
>means.
That seems like the right approach to me.

Cheers,
John

From: TLS  on behalf of Martin Thomson 

Date: Tuesday, 28 November 2023 at 23:11
To: tls@ietf.org 
Subject: Re: [TLS] DTLS 1.3 replay protection of post-handshake messages?
On Tue, Nov 28, 2023, at 19:29, John Mattsson wrote:
> I would strongly recommend all DTLS 1.3 libraries to completely remove
> the option to disable replay protection.

I believe that the reason this exists is that some higher-layer protocols have 
their own replay protection, such that as long as the datagram is authentic, it 
is safe.  However, I agree that if we are sending handshake messages that 
affect DTLS state, it is probably not good to have the DTLS layer fail to 
provide that protection.  I believe that you can operate DTLS 1.3 without 
post-handshake handshake/control messages, in which case you might manage to 
avoid exposure.

NSS has no means to disable replay protection and I see no reason to add that 
means.

___
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

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

[John Mattsson]

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  on behalf of John Mattsson 

Date: Tuesday, 28 November 2023 at 09:30
To: 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  on behalf of John Mattsson 

Date: Friday, 24 November 2023 at 14:50
To: 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

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

[Eric Rescorla]

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  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  on behalf of John Mattsson
> 
> *Date: *Tuesday, 28 November 2023 at 09:30
> *To: *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  on behalf of John Mattsson
> 
> *Date: *Friday, 24 November 2023 at 14:50
> *To: *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

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

[Martin Thomson]

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 
>  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  on behalf of John Mattsson 
>> 
>> *Date: *Tuesday, 28 November 2023 at 09:30
>> *To: *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  on behalf of John Mattsson 
>> 
>> *Date: *Friday, 24 November 2023 at 14:50
>> *To: *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

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

[Tschofenig, Hannes]

John,

when you say that DTLS over SCTP is not a good design (and reference the work 
in the design team) you should also note that you have file IPRs on an 
alternative designed. Hence, I think you are a little bit biased.

Ciao
Hannes

Von: TLS  Im Auftrag von John Mattsson
Gesendet: Dienstag, 28. November 2023 23:58
An: Martin Thomson ; tls@ietf.org
Betreff: Re: [TLS] DTLS 1.3 replay protection of post-handshake messages?

>I believe that the reason this exists is that some higher-layer protocols have 
>their own replay protection, such that as long as the datagram is authentic, 
>it is safe.
I agree that you theoretically do that. But I don't see the problem in these 
cases. Replay protection is almost free. I do understand the use case in RFC 
6083 where DTLS is sent on top of SCTP and having DTLS replay protection turned 
on cause problems. But I also think that DTLS over SCTP is not a good design.

>NSS has no means to disable replay protection and I see no reason to add that 
>means.
That seems like the right approach to me.

Cheers,
John

From: TLS mailto:tls-boun...@ietf.org>> on behalf of 
Martin Thomson mailto:m...@lowentropy.net>>
Date: Tuesday, 28 November 2023 at 23:11
To: tls@ietf.org mailto:tls@ietf.org>>
Subject: Re: [TLS] DTLS 1.3 replay protection of post-handshake messages?
On Tue, Nov 28, 2023, at 19:29, John Mattsson wrote:
> I would strongly recommend all DTLS 1.3 libraries to completely remove
> the option to disable replay protection.

I believe that the reason this exists is that some higher-layer protocols have 
their own replay protection, such that as long as the datagram is authentic, it 
is safe.  However, I agree that if we are sending handshake messages that 
affect DTLS state, it is probably not good to have the DTLS layer fail to 
provide that protection.  I believe that you can operate DTLS 1.3 without 
post-handshake handshake/control messages, in which case you might manage to 
avoid exposure.

NSS has no means to disable replay protection and I see no reason to add that 
means.

___
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

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

[Tschofenig, Hannes]

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  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 mailto:tls-boun...@ietf.org>> on behalf of John 
Mattsson 
mailto:john.mattsson=40ericsson@dmarc.ietf.org>>
Date: Tuesday, 28 November 2023 at 09:30
To: 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 mailto:tls-boun...@ietf.org>> on behalf of John 
Mattsson 
mailto:john.mattsson=40ericsson@dmarc.ietf.org>>
Date: Friday, 24 November 2023 at 14:50
To: 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

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

[Tschofenig, Hannes]

Hi Martin,

I believe the best approach is to address this issue is to use replay 
protection for post-handshake authentication messages. I believe there is value 
in enhancing the functionality of the post handshake authentication, 
particularly the key update message, and we could do it in this context.

FWIW I have prepared a draft that adds new functionality to the key update 
message:
https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-key-update/draft-tschofenig-tls-extended-key-update.txt

Ciao
Hannes

-Ursprüngliche Nachricht-
Von: TLS  Im Auftrag von Martin Thomson
Gesendet: Dienstag, 28. November 2023 23:11
An: tls@ietf.org
Betreff: Re: [TLS] DTLS 1.3 replay protection of post-handshake messages?

On Tue, Nov 28, 2023, at 19:29, John Mattsson wrote:
> I would strongly recommend all DTLS 1.3 libraries to completely remove
> the option to disable replay protection.

I believe that the reason this exists is that some higher-layer protocols have 
their own replay protection, such that as long as the datagram is authentic, it 
is safe.  However, I agree that if we are sending handshake messages that 
affect DTLS state, it is probably not good to have the DTLS layer fail to 
provide that protection.  I believe that you can operate DTLS 1.3 without 
post-handshake handshake/control messages, in which case you might manage to 
avoid exposure.

NSS has no means to disable replay protection and I see no reason to add that 
means.

___
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