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] Deprecating Static DH certificates in the obsolete key exchange document

2024-04-15 20:14 GMT+02:00 Joseph Salowey : > Should the draft deprecate these ClientCertificateTypes and mark the entries > (rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, ecdsa_fixed_ecdh) as 'D' > discouraged? Oh, yes. ___ TLS mailing list TLS@ietf.org

Re: [TLS] Dnsdir early review of draft-ietf-tls-wkech-04

Hi David, Thanks for taking the time to review this. On 15/04/2024 23:44, David Blacka via Datatracker wrote: Reviewer: David Blacka Review result: Ready with Issues This is an early review, so the actual status simply means that I didn't find anything alarming in this draft. Ta. The author

Re: [TLS] Deprecating Static DH certificates in the obsolete key exchange document

Joseph Salowey writes: >At IETF 119 we had discussion that static DH certificates lead to static key >exchange which is undesirable. Has anyone every seen one of these things, meaning a legitimate CA-issued one rather than something someone ran up in their basement for fun? If you have, can I h

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

Regarding UTA or elsewhere, let's see how the buffered KeyUpdates issue pans out. If I haven't missed something, that one seems severe enough to warrants an rfc9147bis, or at least a slew of significant errata, in which case we may as well put the fixups into the main document where they'll be easi

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 UT

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

Thanks, Hannes! Since it was buried in there (my understanding of the issue evolved as I described it), I currently favor option 7. I.e. the sender-only fix to the KeyUpdate criteria. At first I thought we should also change the receiver to mitigate unfixed senders, but this situation should be p

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