Re: [CFRG] [EXTERNAL] Re: (no subject)

[Mike Ounsworth <[e-mail]>]

Hi Watson,

 

I do actually agree with you that if we *could* find one single hybrid KEM that works for all usecases, then that would be great. I don’t disagree with your goal, but I also don’t think it matches the real world.

 

To take an example: S/MIME (either public or private trust) – or more generally, custom applications built on CMS – which are still typically RSA-only ecosystems because ECC never really provided the economic incentive to replace fleets of smartcarads, “don’t fix what aint broke” etc. Plus, many of these environments require FIPS or CC crypto, so any change to crypto code needs to go through re-cert, which is like 18 – 24 months right now. After that, stuff needs to go into pre-prod environments which can have QA cycles as long as 2 years, then you’ve gotta line up with a planned CA expiry or other hardware refresh cycle (some CAs we deal with were, for example stood up in 2005 and have an operational lifetime until 2035). So it’s like 3.5 – 6 years until crypto changes actually see production. I am so jealous of people who can implement shiny new crypto and get it into production within the same year. So jealous. You get to deal with the easiest possible version of this migration problem.

 

For those stubborn ecosystems, if you want to do a PQ migration in an even remotely graceful manner, it’s gotta be adding ML-DSA and ML-KEM to your existing RSA-based infrastructure without making any changes that would require the RSA part to undergo FIPS / CC evaluation again. That cuts down time-to-deployment of having to wait in the FIPS / CC queue, and it gives you options to bolt on now and use opportunistically, rather than have to wait for your CAs to expire naturally, or the last client in your ecosystem to get upgraded.

 

I agree that it would be really nice if everyone could make X-Wing work, but I just don’t see it working out that way.

 

And there are usecases here (like public-trust S/MIME) that are undeniably “Internet”, so I don’t think the IETF can reasonably turn our back on providing the technical building blocks for graceful migration.

 

---

Mike Ounsworth

 

From: Watson Ladd <[e-mail]> 
Sent: Wednesday, February 21, 2024 2:31 PM
To: Mike Ounsworth <[e-mail]>
Cc: Andy Lutomirski <[e-mail]>; Filippo Valsorda <[e-mail]>; CFRG <[e-mail]>
Subject: Re: [CFRG] [EXTERNAL] Re: (no subject)

 

On Wed, Feb 21, 2024 at 12: 13 PM Mike Ounsworth <Mike. Ounsworth@ entrust. com> wrote: > > > Why? We have a hybrid KEM. That's all you need. > > > > You’ll have to forgive me for not knowing which single one you are 



On Wed, Feb 21, 2024 at 12:13 PM Mike Ounsworth
<[e-mail] <mailto:[e-mail]> > wrote:
> 
> > Why? We have a hybrid KEM. That's all you need.
> 
> 
> 
> You’ll have to forgive me for not knowing which single one you are referring to. At my count, we have at least ____ well-motivated candidates for “the one” floating around.
 
Pick one that is a IND-CCA2 KEM. What's a protocol that can't use it,
but could use another?
 
Remember: to deploy you need a new identifier, newly generated key
material, recipients upgrading to accept it and new code to implement.
That's true for all of these, and the costs aren't much different
depending on which one. So why should every WG go pick a different
one?
 
> 
> 
> 
> ML-KEM + X25519 with X25519 CT and PK (“X-Wing”)
> 
> ML-KEM + X25519 that includes both ciphertexts but not public keys.
> 
> X25519Kyber768 that only explicitly includes SS’s because PKs and CTs are already bound in a protocol-level transcript (ex.: draft-ietf-tls-hybrid-design)
> 
> SecP256r2Kyber768 that only explicitly includes SS’s because PKs and CTs are already bound in a protocol-level transcript (ex.: draft-ietf-tls-hybrid-design)
> 
> Sntrup761_X25519 (“Chempat-X”, draft-josefsson-ntruprime-hybrid-01)
> 
> OpenPGP, LAMPS, and probably JOSE / COSE will need to support ECDH hybrids
> 
> LAMPS will probably need to support RSA-KEM and/or RSA-OAEP hybrids.
> 
> 
> 
> Each of those seems well motivated; as in, someone is going to need that and will do it with or without IETF blessing. Better to get IETF / CFRG review and standardization.
 
TLS doesn't need to do the X25519Kyber768: we did it because it was
fast and secure *for TLS*. I'd prefer to see a solution that's
general, called an IND-CCA2 hybrid KEM, and have protocols interface
to it in a way that makes any other KEM drop in: that's way safer for
everyone.
 
> 
> 
> 
> I honestly don’t see how you get from that list to “We have a hybrid KEM. That’s all you need.”
> 
> 
> 
> 
> 
> If CFRG wants to review each one as a one-off, then cool, that could work. But saying that CFRG will produce the winning ML-KEM_X25519 combiner, and any protocol that wants something else is wrong, is … IMO naïve.
 
Having a thousand flowers bloom means cryptographic libraries are more
complex and runs the risk of them exposing terrible combinations,
particularly if they implement special cases like concatenation that
are not safe for all protocols. The nightmare scenario is a generic
combination API getting expressed by some widely used library,
inviting proliferation of bizzare combinations as people build stuff
and have to interop. Meanwhile a IND-CCA2 KEM functions like any other
if the protocol is designed to accept it. In my view that's what we
should aim for.
 
Just as we moved past every protocol putting together MAC and block
ciphers independently to a uniform AEAD registry and interface into
which any faster, stronger, cheaper algorithm should slot, we should
do this for KEMs.
 
Sincerely,
Watson