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

[Kris Kwiatkowski <[e-mail]>]

I support those choices, but would also add P256+Kyber512.
* (1) same reason as below (by Scott)
* (2) to be able to declare security of generated keys in FIPS-mode for
       _both_ - classical and post-quantum schemes (once Kyber is standardized).
After double-checking with NIST today, currently there is no clear plan for
updating SP 800-56A with X25519 (opposite to SP 800-186).

Kind regards,
Kris

On 8/17/22 20:06, Scott Fluhrer (sfluhrer) wrote:
> So that we get an initial answer to this (so we can put it into the draft - of course, we can debate what's in the draft...)
>
> Illari suggested:
>
> X25519+Kyber768
> P384+Kyber768
>
> Well, I would suggest adding in
>
> X25519+Kyber512
>
> For those situations where we need to limit the message size (perhaps DTLS and QUIC).
>
> Is the working group happy with that?
>
>> -----Original Message-----
>> From: TLS<[e-mail]>  On Behalf Of Ilari Liusvaara
>> Sent: Saturday, August 13, 2022 11:12 AM
>> To:[e-mail]
>> Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
>>
>> On Fri, Aug 12, 2022 at 06:13:38PM +0000, Scott Fluhrer (sfluhrer) wrote:
>>> Again, this is late, however Stephen did ask this to be discussed in the
>> working group, so here we go:
>>>> -----Original Message-----
>>>> From: TLS<[e-mail]>  On Behalf Of Stephen Farrell
>>>> Sent: Saturday, April 30, 2022 11:49 AM
>>>> To: Ilari Liusvaara<[e-mail]>;[e-mail]
>>>> Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
>>>>
>>>>
>>>> Hiya,
>>>>
>>>> On 30/04/2022 10:05, Ilari Liusvaara wrote:
>>>>> On Sat, Apr 30, 2022 at 01:24:58AM +0100, Stephen Farrell wrote:
>>>>>> - section 5: IMO all combined values here need to have
>>>>>> recommended == "N" in IANA registries for a while and that needs
>>>>>> to be in this draft before it even gets parked. Regardless of
>>>>>> whether or not the WG agree with me on that, I think the current
>>>>>> text is missing stuff in this section and don't recall the WG
>>>>>> discussing that
>>>>> I think that having recommended = Y for any combined algorithm
>>>>> requires NIST final spec PQ part and recommended = Y for the
>>>>> classical part (which allows things like x25519 to be the classical part).
>>>>>
>>>>> That is, using latest spec for NISTPQC winner is not enough. This
>>>>> impiles recommended = Y for combined algorithm is some years out
>>>>> at the very least.
>>>> I agree, and something like the above points ought be stated in the
>>>> draft after discussion in the WG.
>>> Section 5 is 'IANA considerations', and would be where we would list
>>> the various supported hybrids, which we don’t at the moment.
>>>
>>> Well, if we were to discuss some suggested hybrids (and we now know
>>> the NIST selection), I would suggest these possibilities:
>>>
>>> - X25519 + Kyber512
>>> - P256 + Kyber512
>>> - X448 + Kyber768
>>> - P384 + Kyber768
>> I would take:
>>
>> X25519+Kyber768
>> P384+Kyber768
>>
>> The reason for taking Kyber768 is because the CRYSTALS team recommends
>> it. The reason for taking P384 is because it is CNSA-approved, so folks that
>> need CNSA can use that.
>>
>> Of course, that is likely to bust packet size limits. I do not think that is an
>> issue in TLS, but DTLS and QUIC might be another matter entierely (in theory
>> DTLS and QUIC can handle it just fine, practice might be another matter
>> entierely. And if such problems are there, it is good to know about those...
>> This stuff is experimental).
>>
>>
>>> Of course, it's possible that NIST will tweak the definition of Kyber;
>>> that's just a possibility we'll need to live with (and wouldn't change
>>> what hybrid combinations we would initially define)
>> I would think such changes would just mean the interim post-quantum kex is
>> not compatible with the final one. Not that big of deal, there are tens of
>> thoursands of free codepoints. If an implementation  needs both, it can
>> probably share vast majority of the code.
>>
>>
>>
>> -Ilari
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls