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

["Kampanakis, Panos" <[e-mail]>]

I forgot to suggest to add a paragraph in the Sec Considerations section about Kyber-512.

Kyber-512 offers a CoreSVP hardness of ~120 bits of security which is a little lower than it should. The Kyber submission refines the CoreSVP cost by using sieving cost simulations and claims that the gate and memory cost is ~2^150 and ~2^90 approximately which they argue is better than AES. I think it would be worth to call out the CoreSVP hardness and the refined estimate for Kyber-512 in the Sec Considerations section.



From: Kampanakis, Panos
Sent: Wednesday, August 17, 2022 4:26 PM
To: 'Kris Kwiatkowski' <[e-mail]>; [e-mail]
Subject: RE: [EXTERNAL][TLS] WGLC for draft-ietf-tls-hybrid-design

+1 on the 3 proposed by Scott and P256+Kyber512 proposed by Kris.

From: TLS <[e-mail]<mailto:[e-mail]>> On Behalf Of Kris Kwiatkowski
Sent: Wednesday, August 17, 2022 3:31 PM
To: [e-mail]<mailto:[e-mail]>
Subject: RE: [EXTERNAL][TLS] WGLC for draft-ietf-tls-hybrid-design


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



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]><mailto:[e-mail]> On Behalf Of Ilari Liusvaara

Sent: Saturday, August 13, 2022 11:12 AM

To: [e-mail]<mailto:[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]><mailto:[e-mail]> On Behalf Of Stephen Farrell

Sent: Saturday, April 30, 2022 11:49 AM

To: Ilari Liusvaara <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/tls

_______________________________________________

TLS mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/tls