On Sat, Apr 30, 2022, at 00:24, Douglas Stebila wrote:
> 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?
Definitely. It's just that - for now at least - it seems very likely that some
of the component algorithms will not be standalone key exchange methods (or
groups).
>> 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?
The diagram of the key schedule (which really needs a figure number) is quite
obviously a diff. Apart from that piece, it's probably OK.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
