[TLS] ECH-13 HRR Signal Derivation

I have two questions about the transcript for the confirmation signal for HelloRetryRequests in ECH Draft 13: 1. Should ClientHelloInner1 be replaced with a message_hash message as in TLS? 2. Is th

Re: [TLS] ECH-13 HRR Signal Derivation

On Thu, Sep 2, 2021, at 1:42 AM, Dennis Jackson wrote: > I have two questions about the transcript for the confirmation signal > > for HelloRetryRequests in ECH Draft 13: > > 1. Should ClientHelloInne

Re: [TLS] Combining Secrets in Hybrid Key Exchange in TLS 1.3

The APOP attack demonstrates that concatenating secrets may be dangerous, as a general cryptographic practice. As to the TLS KDF, if future SHA256 cryptanalysis results in collisions, an attacker that can establish multiple PSKs of their choice with another party can cause two sessions with two dif

Re: [TLS] Combining Secrets in Hybrid Key Exchange in TLS 1.3

Dear Nimrod and team: How does your concern compare to Campagna and Petcher’s report https://eprint.iacr.org/2020/1364 which has security proofs for concatenation-based KDF? (Maybe a detailed discussion is better suited to CFRG?) Best regards, ​Dan From: TLS On Behalf Of Nimrod Avira

Re: [TLS] Combining Secrets in Hybrid Key Exchange in TLS 1.3

The APOP attack demonstrates that concatenating secrets may be dangerous, as a general cryptographic practice. I disagree with the word “general” here. As to the TLS KDF, if future SHA256 cryptanalysis results in collisions, Since (if memory serves me) KDF is HMAC-based, rather than me

Re: [TLS] Combining Secrets in Hybrid Key Exchange in TLS 1.3

Regarding the TLS 1.3 proof, I recall some discussion around collision-resistance and PSK binders, with the result that we assume the KDF is collision-resistant. The paragraph that begins "The PSK binder value forms a binding" in Appendix E.1: https://datatracker.ietf.org/doc/html/rfc8446#appendix

Re: [TLS] progressing draft-ietf-tls-md5-sha1-deprecate

Just a reminder that sometime tomorrow I will ask for these PRs to be merged and a new version of the I-D be produced so that we can make progress. spt > On Aug 27, 2021, at 10:58, Sean Turner wrote: > > Hi! While address the IoT Directorate comments from IETF LC, some addition > comments hav

Re: [TLS] tls-flags: abort on malformed extension

Seems pretty reasonable to me. spt > On Aug 28, 2021, at 16:36, Yoav Nir wrote: > > Hi. > > To address Michael StJohns comment from 19-July, I submitted PR #12: > > https://github.com/tlswg/tls-flags/pull/12 > > What is says is that any implementation receiving a malformed tls_flags > exten

Re: [TLS] tls-flags: abort on malformed extension

On Sat, Aug 28, 2021 at 1:37 PM Yoav Nir wrote: > The text provides a list (which I hope is comprehensive) of all the ways > this specific extension can be malformed. > The text says "Such invalid tls_flags extensions include: ..." While I don't oppose the edit, I don't understand why this WG