Re: [lamps] Security Consideration for draft-turner-lamps-nist-pqc-kem-certificates

[Mike Ounsworth <[e-mail]>]

> assuming that we use the NIST algorithms as they’re defined, the length of the shared secret shouldn't be ambiguous as it will be part of the parameter set for the KEM.

Oh that’s good to know!
I saw that many (most? all?) of the remaining KEMs use SHAKE as their last internal step, so in theory they are variable-length, but if the NIST specs will fix the output length then that’s probably sufficient.

The experts in this case are @Nimrod Aviram<mailto:[e-mail]>, and @Douglas Stebila<mailto:[e-mail]>.

---
Mike Ounsworth

From: Florence D <Florence.D=[e-mail]>
Sent: March 25, 2022 8:09 AM
To: Mike Ounsworth <[e-mail]>; 'LAMPS' <[e-mail]>
Subject: [EXTERNAL] RE: [lamps] Security Consideration for draft-turner-lamps-nist-pqc-kem-certificates

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
> We’re putting together a draft which provides essentially the same combiner for hybrid CMS content encryption (yuck terminology hell. Florence D. please save us and write a terminology draft!).

Very happy to write something.  I suspect the word hybrid is already so overloaded that agreeing on anything will be much more difficult but I’m happy to get started.

> At the TLS WG this week, Douglas Stebila presented on a known issue in the hybrid KEM combiner they’re proposing for TLS (draft-ietf-tls-hybrid-design): it gets into trouble if the attacker gets to play with the lengths of the shared secrets at runtime. Obvious solution: KEM codepoints need to fix the SS length in the spec so that it’s not variable at runtime.
On the shared secret length, assuming that we use the NIST algorithms as they’re defined, the length of the shared secret shouldn't be ambiguous as it will be part of the parameter set for the KEM.  If we’re proposing doing something different then this probably merits some security analysis of its own.   I’ll defer to more experienced protocol designers on whether it’s worth encoding the length in the codepoint if it’s implicit from the scheme, I’m not sure of the precedent.

Flo

From: Spasm <[e-mail]<mailto:[e-mail]>> On Behalf Of Mike Ounsworth
Sent: 25 March 2022 11:17
To: 'LAMPS' <[e-mail]<mailto:[e-mail]>>
Subject: [lamps] Security Consideration for draft-turner-lamps-nist-pqc-kem-certificates

The comment I was going to make at the mic:

At the TLS WG this week, Douglas Stebila presented on a known issue in the hybrid KEM combiner they’re proposing for TLS (draft-ietf-tls-hybrid-design): it gets into trouble if the attacker gets to play with the lengths of the shared secrets at runtime. Obvious solution: KEM codepoints need to fix the SS length in the spec so that it’s not variable at runtime.

We’re putting together a draft which provides essentially the same combiner for hybrid CMS content encryption (yuck terminology hell. Florence D. please save us and write a terminology draft!).
For that combiner to avoid the attack, I think we need Sean’s KEM OIDs draft to fix the shared secret length for each KEM that it specifies.

So for now I think I’m just asking @Sean to throw a Security Consideration into his draft so we don’t forget that it’s important.

---
Mike Ounsworth
Software Security Architect, Entrust

Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system. This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to [e-mail]<mailto:[e-mail]>. All material is UK Crown Copyright ©