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

[Hubert Kario <[e-mail]>]

On Saturday, 1 April 2023 03:50:04 CEST, Krzysztof Kwiatkowski wrote:
>> I would pair secp384r1 with Kyber768 for completely different reasons:
>> Kyber768 is what the team kyber recommends.
> Agreed.
>
>> 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.
>> 
> From my perspective, the two reasons for including a NIST curves are:
> 1. To have an option for those who require FIPS compliance. In 
> a short term at least one key agreement scheme should be 
> FIPS-approved. In the long term both of them should be 
> fips-approved. That way, in case security of Kyber768 falls 
> below 112-bits or simply implementation is broken, one can still 
> run key agreement in FIPS compliant manner. In the end, the 
> ultimate goal of hybrid-tls draft is to ensure that at least one 
> of the schemes provides security if the other gets broken. Would 
> be good to use this in FIPS context also.
> 2. NIST curves are more often implemented in HW than 
> Curve25519. When working with chips like ATECC608B, one ideally 
> only adds SW-based Kyber and can reuse existing HW-based ECDH. 
> Such migration is simpler, less risky and time-consuming than 
> adding SW-based X25519.
>

there's a third reason: the public CAs that support ECDSA almost 
exclusively
support just P-256 and P-384, so if somebody implements ECDSA for the 
public
internet, they have to support those two curves at the very least.

-- 
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic