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

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

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

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

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

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

[TLS] Design Rational for Key Exporter

Hi all, I was wondering why the design of the key exporter is such that it is based on the early_exporter_master_secret or the exporter_master_secret and no new key export is triggered at a later point in time, for example when a key update is performed. RFC 5705, which is used as a basis for t

[TLS] Key Update for TLS/DTLS 1.3

Hi all, we have just submitted a draft that extends the key update functionality of TLS/DTLS 1.3. We call it the "extended key update" because it performs an ephemeral Diffie-Hellman as part of the key update. The need for this functionality surfaced in discussions in a design team of the TSVW

Re: [TLS] DTLS 1.3 epochs vs message_seq overflow

Hi David, thanks for your reviews and the details comments. Let me search for the exchanges that lead to the increase in the epoch space. I recall that this was very late in the process based on feedback from John, who noticed that the smaller epoch space helps IoT communication but not the DTL

Re: [TLS] DTLS 1.3 sequence number lengths and lack of ACKs

Hi David, thanks again for these comments. Speaking for myself, this exchange was not designed based on QUIC. I believe it pre-dated the corresponding work in QUIC. Anyway, there are different usage environments and, as you said, there is a difference in the amount of messages that may be lost

Re: [TLS] Issues with buffered, ACKed KeyUpdates in DTLS 1.3

Hi David, this is great feedback. Give me a few days to respond to this issue with my suggestion for moving forward. Ciao Hannes From: TLS On Behalf Of David Benjamin Sent: Saturday, April 13, 2024 7:59 PM To: Cc: Nick Harper Subject: Re: [TLS] Issues with buffered, ACKed KeyUpdates in DTLS

Re: [TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks

Hi John, I missed this email exchange and I largely agree with what has been said by others before. I disagree with your conclusion since the “identity” in the raw public key case is the public key. With the self-signed certificate there would the danger that the self-asserted identity in the

Re: [TLS] DTLS 1.3 sequence number lengths and lack of ACKs

Fair enough. I don’t have a strong preference as long as we document it somewhere. Ciao Hannes From: David Benjamin Sent: Tuesday, April 16, 2024 3:18 PM To: Tschofenig, Hannes (T CST SEA-DE) Cc: ; Nick Harper Subject: Re: [TLS] DTLS 1.3 sequence number lengths and lack of ACKs Regarding

Re: [TLS] [rfc9147] Clarification on DTLS 1.3 CID Retirement and Usage

Hi Kristijan, searching through the mailing list I found this mail. So, sorry for the late response. The CID design in DTLS 1.3 has not been focused on multi-homing use cases. It was not a design goal; you have to design on an extension in the style of what is currently happening with QUIC or