Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Ilari Liusvaara <[e-mail]>]

On Wed, Mar 29, 2023 at 02:59:51PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
> Because that’s what CNSA requires. 

I don't think that is the case. CNSA1 does not consider the Kyber part,
and CNSA2 requires something that is not currently available.

 
> > On Mar 29, 2023, at 00:45, Kampanakis, Panos <[e-mail]> wrote:
> > 
> > 
> >  
> > > I would also like secp384r1_kyber1024 option, please.
> >  
> > Why do you up the ECDH curve sec level with Kyber1024? It adds
> > unnecessary size to the keyshare. like secp384r1_kyber768
> > combines two equivalent security levels.

Is that the case? Secp384r1 is 192-level DH, but Kyber768 is quoted to
be Category III (and I think it is not significantly above Category III
requirements), which is defined as equivalent to 192-level encryption.
192-level DH is stronger than 192-bit encryption.

(Another illustration of numbers not being comparable is that Category
IV is defined as equivalent to 192-level hash.)

I would pair secp384r1 with Kyber768 for completely different reasons:
Kyber768 is what the team kyber recommends.


> > From: TLS <[e-mail]> On Behalf Of Blumenthal, Uri - 0553 - MITLL
> > Sent: Tuesday, March 28, 2023 10:40 PM
> > To: Krzysztof Kwiatkowski <[e-mail]>; Christopher Wood <[e-mail]>
> > Cc: [e-mail]
> > Subject: RE: [EXTERNAL][TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design
> >  
> > Can we add secp256r1_kyber768 option for those who prefer NIST
> > curves?
> >  
> > I support this.
> >  
> > I would also like secp384r1_kyber1024 option, please.
> >  
> > Thanks

I don't think there are very good reasons for NIST curves here outside
wanting CNSA1 compliance, and for that you need secp384r1 classical
part. And for that, I would pick secp384r1_kyber768.




-Ilari