Thanks for the feedback Martin. I see what you're getting at regarding phrasing it in terms of KeyGen[i], Encaps[i], etc. This is a good point:
>> For a hybrid key exchange, the key_exchange field of a KeyShareEntry is the >> concatenation of the key_exchange field for each of the constituent >> algorithms. > > I think that this text is a mistake as it implies that the component key > exchange algorithm has a defined key_exchange format. What you want is a > definition in the form above, or as HPKE has it. Indeed it makes sense to be able to define a hybrid key exchange method independent of whether the all of the component algorithms are already defined standalone key exchange methods in TLS 1.3. I do however want to tie back somehow to the idea that, *if* one of the algorithms is already defined as a key exchange method in TLS 1.3, then the value that should be put in the key share concatenation is just the key share that was used when it was a standalone method. Is that okay? > With something like this, I'd like to see the implication that the TLS key > schedule is changed by this draft can be removed (in Section 3.3 > specifically). I don't read Section 3.3 as implying that the TLS key schedule is changed. It says how one of the inputs to the key schedule is computed, but otherwise I think it's just saying: put this concatenated value into the obvious place in the existing key schedule. Can you point me to where you read it as implying more changes to the TLS key schedule? Douglas > On Apr 27, 2022, at 20:56, Martin Thomson <m...@lowentropy.net> wrote: > > I found the introduction of KeyGen, Encaps, and Decaps to be underutilized. > It would require a little work, but I think that it would be better to > describe a method whereby you produce each of these functions by taking an > ordered collection of these functions (KeyGen[i], Encaps[i], and Decaps[i]) > and constants (Npk[i], Nek[i], etc...). > > With something like this, I'd like to see the implication that the TLS key > schedule is changed by this draft can be removed (in Section 3.3 > specifically). > > In essence, you are describing a known-good process for composing key > exchange methods. (Not existing TLS 1.3 key exchange methods, as implied by > this: > >> For a hybrid key exchange, the key_exchange field of a KeyShareEntry is the >> concatenation of the key_exchange field for each of the constituent >> algorithms. > > I think that this text is a mistake as it implies that the component key > exchange algorithm has a defined key_exchange format. What you want is a > definition in the form above, or as HPKE has it. > > I'd prefer to see this work done before publication, but as I'm not able to > volunteer to do it, I can't really insist on it. This is useful work and the > document, despite these niggles, is pretty clear and well-reasoned. > > On Thu, Apr 28, 2022, at 01:27, Christopher Wood wrote: >> This email commences a two week WGLC for draft-ietf-tls-hybrid-design, >> located here: >> >> https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/ >> >> We do not intend to allocate any code points at this time and will park >> the document after the call is complete. Once CFRG produces suitable >> algorithms for consideration, we will then add them to the NamedGroup >> registry through the normal process [1] and move the document forward. >> >> Please review the draft and send your comments to the list. This WGLC >> will conclude on May 13. >> >> Best, >> Chris, for the chairs >> >> [1] >> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
