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

[Mike Ounsworth <[e-mail]>]

> So if your scenario envisions concatenating a traditional (RSA/FFDH/ECC) shared secret and a PQ shared secret, one would want to be sure the first component of the concatenation is not variable length.

Another good point!

Thinking out loud: does padding solve the problem?

H(ss_1 || ss_2 || .. || ss_n)

if ss_i are each padded / truncated to, say, the security level of the underlying hash function, does that work?

---
Mike Ounsworth

-----Original Message-----
From: Douglas Stebila <[e-mail]> 
Sent: March 25, 2022 8:24 AM
To: Mike Ounsworth <[e-mail]>
Cc: Florence D <Florence.D=[e-mail]>; LAMPS <[e-mail]>; Nimrod Aviram <[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.

______________________________________________________________________
On Mar 25, 2022, at 9:14 AM, Mike Ounsworth <[e-mail]> wrote:
> 
> > 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.

All of the round 3 KEM finalists and alternate candidates have fixed length shared secrets, even if they happen to be using the extendable output function SHAKE internally while generating the shared secret.

But it's not just the PQ shared secret that would need to be fixed length.  If one is concatenating two shared secrets and then hashing -- H(ss_1 || ss_2) -- the concern arises when ss_1 is variable-length.  So if your scenario envisions concatenating a traditional (RSA/FFDH/ECC) shared secret and a PQ shared secret, one would want to be sure the first component of the concatenation is not variable length.  For TLS 1.3 key exchange, the number of standardized curves is quite small so one can reasonably have confidence the scenario won't arise.  For general certificates with arbitrary algorithms, I can see there being a long tail of peculiar algorithms, some of which might be variable-length, so this scenario might merit some extra care.

> 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.


To be clear on the context here, there are additional requirements that have to be satisfied for there to be trouble, not the least of which is the ability to find collisions in the hash function used on concatenated secrets.

Douglas

>  
> The experts in this case are @Nimrod Aviram, and @Douglas Stebila.
>  
> ---
> 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]> On Behalf Of Mike Ounsworth
> Sent: 25 March 2022 11:17
> To: 'LAMPS' <[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]. All material is UK Crown Copyright ©