Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

[Martin Thomson <[e-mail]>]

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.