[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM KeyAgreement for TLSv1.3

[Alicja Kario <[e-mail]>]

On Thursday, 13 March 2025 06:55:48 CET, Loganaden Velvindron wrote:
> On Sat, 1 Mar 2025 at 00:22, Stephen Farrell 
> <[e-mail]> wrote:
>> 
>> 
>> Hiya,
>> 
>> On 28/02/2025 18:56, Sean Turner wrote:
>>> In response to the WG adoption call, Dan Bernstein pointed out some
>>> potential IPR (see [0]), but no IPR disclosure has been made in
>>> accordance with BCP 79.
>> 
>> While I don't think the lack of an IPR declaration is fatal
>> here, I do think it'd be great if that uncertainty could be
>> reduced. I think I saw that Russ tried to reach out to one
>> of the possible patent holders to ask if they'd be willing
>> to make a declaration. I've no idea where that's at, but I'd
>> encourage the TLS chairs and SEC ADs to see if they can help
>> get that to happen as reducing uncertainty would be good and
>> if we can't, then this topic will just keep cropping up and
>> Dan is not the only person I've heard express concerns in
>> this regard.
>> 
>
> I agree with Dr Stephen on this one. It would help if we can get
> declarations from
> patent holders early.
>
> For example, OpenSSH implemented DSA as there was less risk of patents:
>
> "
> The second major variety of SSH is the SSH 2 protocol. SSH 2 was
> invented to avoid the patent issues regarding RSA (patent issues which
> no longer apply, since the patent has expired), to fix the CRC data
> integrity problem that SSH1 has, and for a number of other technical
> reasons. By requiring only the asymmetric DSA and DH algorithms,
> protocol 2 avoids all patents.
> "
>
> If there is any risk of a patent, can we look at a backup choice for
> ML-KEM in TLS,
> especially for implementers who are very patent averse ?
>
> Should I start a new thread ?

NIST has selected HQC for standardisation this week... No idea about
its patent situation, or if we want something with ciphertexts this big in
TLS... (reminder: 4.4 kiB, 8.8 kiB, and 14.1 kiB for 128, 192 and 256
bit level of security respectively)
-- 
Regards,
Alicja Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic