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, Reque
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 a
>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 un
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
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 de
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.
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
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 b
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 c
