Re: [TLS] Revised hybrid key exchange draft

On Jan 22, 2022, at 06:35, Nimrod Aviram wrote: > > > The nice thing about the hybrid draft is that it isn't a firm commitment to > > any particular combination method. > > It only suggests a method. > > That's not my understanding. My reading is that the draft prescribes a > combination meth

Re: [TLS] Revised hybrid key exchange draft

Nimrod Aviram writes: > The construction is proven to satisfy this property under precise > assumptions about its components. So, to be clear, the statement that a function F provides "provable security" means that there's a proof that F achieves the security property under discussion (in this cas

Re: [TLS] Revised hybrid key exchange draft

Thank you for the discussion :-) 1. The construction is proven to satisfy this property under precise assumptions about its components. A formal theorem statement can be found in Theorem 1 on page 11 of ePrint 2022/065 . A discussion of how to instantiate those co

Re: [TLS] Revised hybrid key exchange draft

Nimrod Aviram writes: [ regarding the "dual-PRF" security property ] > Our construction satisfies this property. To make sure I understand: (1) You mean that the construction is _conjectured_ to satisfy this property, i.e., to be a dual PRF? There must be some sort of limit on

Re: [TLS] Revised hybrid key exchange draft

Current proofs for TLS 1.3 generally require HKDF to act as a dual-PRF (or as a random oracle - an even stronger assumption). HKDF has not yet been proven to satisfy this property, under any assumption. Our construction satisfies this property. best, Nimrod On Mon, 24 Jan 2022 at 17:13, D. J. Be

Re: [TLS] Revised hybrid key exchange draft

I don't see much benefit in the revised construction. -- Regards, Uri There are two ways to design a system. One is to make it so simple there are obviously no deficiencies. The other is to make it so complex there are no obvious deficiencies.

Re: [TLS] Revised hybrid key exchange draft

Nimrod Aviram writes: > To summarize, we recommend using our new proposed construction. It’s fast, > easy to implement, and provides provable security. The baseline construction is faster and is easier to implement, so you're saying it doesn't provide "provable security"? Can you please clarify

Re: [TLS] Revised hybrid key exchange draft

Hi all, I think this work is an interesting examination of the assumptions, and as a new key schedule it might be worth considering for future version numbers of TLS and other protocols that rely on dual-PRF. Computationally, a few extra hashes won't hurt anyone. However, I don't agree with the s

Re: [TLS] Revised hybrid key exchange draft

I think that Martin is asking what properties this provides that justify the additional complexity. I'm sure that a few test vectors are sufficient to get interoperability, but what properties of the construction justify the effort to do something different? Russ > On Jan 22, 2022, at 6:35 A

Re: [TLS] Revised hybrid key exchange draft

> I might have preferred a more efficient option though. By efficient, are you referring to the computation cost, or the implementation complexity? As to the former, the new construction requires ~7 microseconds, whereas HKDF.extract requires ~1. As to the implementation complexity, if that's your

Re: [TLS] Revised hybrid key exchange draft

I am not convinced that the extra effort is justified. However, I am convinced that the proposed construction is complex. combined_key = H(HMAC(key=H1(k1), data=2||F(k2)) xor HMAC(key=H2(k2), data=1||F(k1))) H1(k) = H('derive1' || k) H2(k) = H('derive2' || k) F(m) = H(0||m1)||H(1||m1)||...||H(j-

Re: [TLS] Revised hybrid key exchange draft

Hi Everyone, As Douglas wrote, we have discussed the issues together at length, and we thank him for the productive (and friendly :-)) conversation. Our paper, which describes our concerns, can be found here: https://eprint.iacr.org/2022/065 And a reference implementation of our proposed KDF: ht

Re: [TLS] Revised hybrid key exchange draft

On Jan 11, 2022, at 19:07, Martin Thomson wrote: > > I was operating under the assumption that inputs to concatenation were fixed > length. It seems that the attack mentioned did not. It seems like that is a > far simpler way of achieving that goal. > > That is, it seems to be sufficient t

Re: [TLS] Revised hybrid key exchange draft

From: TLS On Behalf Of Eric Rescorla Sent: Tuesday, January 11, 2022 4:01 PM To: Douglas Stebila Cc: Subject: Re: [TLS] Revised hybrid key exchange draft … With that said, defense in depth is good. Does it help to have just a structured input, e.g., opaque KeyInput<0..2^16-1>;

Re: [TLS] Revised hybrid key exchange draft

I was operating under the assumption that inputs to concatenation were fixed length. It seems that the attack mentioned did not. It seems like that is a far simpler way of achieving that goal. That is, it seems to be sufficient to state that assumption as a requirement. Constructing a lengt

Re: [TLS] Revised hybrid key exchange draft

Hi Douglas, 8446 already says: Note that HKDF-Expand implements a pseudorandom function (PRF) with both inputs and outputs of variable length. In some of the uses of HKDF in this document (e.g., for generating exporters and the resumption_master_secret), it is necessary that the appl

[TLS] Revised hybrid key exchange draft

Hello TLS working group, We've posted a revised version of "Hybrid key exchange in TLS 1.3" [1]. Based on revision requests from the last draft, the main change is removing the unnecessary appendix of the past design considerations, and a few wording changes. Last September, Nimrod Aviram, Be