Re: [CFRG] [EXTERNAL] What I want from the "KEM hybrids"

[Hubert Kario <[e-mail]>]

On Wednesday, 21 February 2024 16:59:28 CET, Mike Ounsworth wrote:
>> For JWA/JWE PKCS#1v1.5 is already dead: no browser allows PKCS#1v1.5 
>> encryption in webcrypto API.
>  
> You’re trying to claim that JWE is only used in browsers? 
> Backend-to-backend JWE doesn’t count?
>  
> PKCS#1v1.5 encryption still seems to be supported in the two 
> largest JWE libraries for java:
>  
> https://javadoc.io/doc/com.nimbusds/nimbus-jose-jwt/latest/index.html
>  
> https://javadoc.io/doc/org.bitbucket.b_c/jose4j/latest/org/jose4j/jwe/RsaKeyManagementAlgorithm.Rsa1_5.html
>  

fair point

>  
>> Now in the wider context: Will there people that continue to do stupid
>> things? Absolutely.
>> Should we make it easy for them to do stupid things? I don't think so.
>  
> This is a fair point, but I would phrase it as “If we know that 
> people are going to do stupid things anyway, can we help them do 
> it less stupidly?”

and that is the "define RSA-OAEP+Kyber"

> ---
> Mike Ounsworth
>  
> From: Hubert Kario <[e-mail]> 
> Sent: Wednesday, February 21, 2024 9:52 AM
> To: Mike Ounsworth <[e-mail]>
> Cc: Watson Ladd <[e-mail]>; CFRG <[e-mail]>
> Subject: Re: [CFRG] [EXTERNAL] What I want from the "KEM hybrids"
>  
> Not aware of anything CMS specific. My draft is a general 
> recommendation. For JWA/JWE PKCS#1v1. 5 is already dead: no 
> browser allows PKCS#1v1. 5 encryption in webcrypto API. Now in 
> the wider context: Will there people that continue to do stupid
> Not aware of anything CMS specific.
> My draft is a general recommendation.
> For JWA/JWE PKCS#1v1.5 is already dead: no browser allows PKCS#1v1.5 
> encryption in webcrypto API.
>  
> Now in the wider context: Will there people that continue to do stupid
> things? Absolutely.
> Should we make it easy for them to do stupid things? I don't think so.
>  
> On Wednesday, 21 February 2024 16:37:30 CET, Mike Ounsworth wrote:
>> Hi Hubert,
>>  
>> That’s a TLS-specific draft. Is there anything that would cover 
>> PKCS#1 usage in CMS or JOSE (JWA)?
>>  
>> ---
>> Mike Ounsworth
>>  
>> From: Hubert Kario <[e-mail]> 
>> Sent: Wednesday, February 21, 2024 9:30 AM
>> To: Mike Ounsworth <[e-mail]>
>> Cc: Watson Ladd <[e-mail]>; CFRG <[e-mail]>
>> Subject: Re: [CFRG] [EXTERNAL] What I want from the "KEM hybrids"
>>  
>> On Wednesday, 21 February 2024 16: 12: 58 CET, Mike Ounsworth 
>> wrote: >> If we don't provide OIDs for combined PKCS#1/Kyber, 
>> then people won't > be using it. > > That’s optimistic 😊 > I 
>> think it means that people won’t be using
>> On Wednesday, 21 February 2024 16:12:58 CET, Mike Ounsworth wrote:
>>>> If we don't provide OIDs for combined PKCS#1/Kyber, then people won't
>>> be using it.
>>>  
>>> That’s optimistic 😊
>>> I think it means that people won’t be using it in a 
>>> standardized and peer-reviewed way, which might be worse.
>>>  
>>> Hypothetical situation: an organization has a FIPS certified 
>>> implementation of RSAencryption-PKCS#1v1.5.
>>  
>> It's purely hypothetical, as in FIPS mode you're not allowed to use
>> PKCS#1v1.5 since 1st of January 2024, no matter when your cryptographic
>> module received certification.
>>  
>>> Once FIPS 203 drops 
>>> in June – August 2024, it will take X years go get ML-KEM 
>>> through the FIPS certification, but in the meantime they can 
>>> claim FIPS-certification on a PKCS#1/Kyber hybrid. If the IETF 
>>> is only giving OIDs for OAEP/Kyber and RSA-KEM/Kyber, then they 
>>> will have to implement new OAEP or RSA-KEM code and run that 
>>> through FIPS certification that will equivalently take X years. 
>>> That’s a strong reason to use PKCS#1/Kyber, whether or not the 
>>> IETF has provided an OID for it.
>>>  
>>> I’m not necessarily saying that people *are* going to do this 
>>> (I need to do some homework here too), but I think that *IF* 
>>> people are going to do this, then it’s probably worth doing 
>>> properly in a standardized and peer-reviewed way.
>>>  
>>> By the way #1: Is there an RFC that formally deprecates 
>>> RSAencryption-PKCS#1v1.5?
>>  
>> not yet: 
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/__;!!FJ-Y8qCqXTj2!c7bWTChVknVaBqExzLbeF7OCgpQiCWsgL9FQuQkxaJLCWqsY-JR2NiTA5OJL7hvAALBCQN8MBWKYV4YH46I$
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-kario-rsa-guidance/__;!!FJ-Y8qCqXTj2!c7bWTChVknVaBqExzLbeF7OCgpQiCWsgL9FQuQkxaJLCWqsY-JR2NiTA5OJL7hvAALBCQN8MBWKYPz0v_RM$
>> 
>> but it's basically a done deal at this point
>>  
>>> By the way #2: no argument that RSA-OAEP is in all ways better, 
>>> but for my education, I am aware of the Bleichenbacher attack, 
>>> and that there exist many bad implementations of PKCS#1v1.5, but 
>>> also that in absence of an exploitable decryption oracle, right?
>>  
>> The whole issue with PKCS#1v1.5 is that padding check error is the 
>> information
>> that the attacker is looking for.
>>  
>> Normal way of handling errors is to raise an exception, or 
>> push it to error
>> stack, or do 100 other ways that triggers a different code path than
>> regular decryption. That means that error processing generally will have
>> a different timing characteristic than successful decryption, making
>> the attack easy.
>>  
>> Handling that error in side-channel free way requires two page-long 
>> description
>> in the TLS RFC 
>> (https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc5246*section-7.4.7.1__;Iw!!FJ-Y8qCqXTj2!c7bWTChVknVaBqExzLbeF7OCgpQiCWsgL9FQuQkxaJLCWqsY-JR2NiTA5OJL7hvAALBCQN8MBWKYqRHgGGk$)
>>and the TLS gets away with it only because the PMS is also mixed with
>> ServerHello.random before using it for encryption key derivation.
>> Protocols like CMS don't have that luxury.
>>  
>>> Also,
>>>  
>>> ---
>>> Mike Ounsworth
>>>  
>>> From: Hubert Kario <[e-mail]> 
>>> Sent: Wednesday, February 21, 2024 8:22 AM
>>> To: Mike Ounsworth <[e-mail]>
>>> Cc: Watson Ladd <[e-mail]>; CFRG <[e-mail]>
>>> Subject: Re: [CFRG] [EXTERNAL] What I want from the "KEM hybrids"
>>>  
>>> On Wednesday, 21 February 2024 00: 07: 25 CET, Mike Ounsworth 
>>> wrote: > Hi Watson, Sophie, Hubert, > > I’ll reply all at once. 
>>> > > > The point of having ML-KEM + RSA hybrids is not about 
>>> reusing > *keys*, which I agree should
>>> On Wednesday, 21 February 2024 00:07:25 CET, Mike Ounsworth wrote:
>>>> Hi Watson, Sophie, Hubert,
>>>>  
>>>> I’ll reply all at once.
>>>>  
>>>>  
>>>> The point of having ML-KEM + RSA hybrids is not about reusing 
>>>> *keys*, which I agree should not be done, but about reusing 
>>>> *code*. For the ultra-conservative crowd, being able to put 
>>>> their existing code (again, “code”, not “keys”) into hybrid 
>>>> reduces the migration risk.
>>>>  
>>>> Hubert, I am not trying to suggest that RSA_PKCS#1v1.5 is 
>>>> acceptable in any academic sense, but I am suggesting that it 
>>>> still very much exists in the wild in applications which need 
>>>> migrate-out strategies. If you want to leverage ML-KEM in 
>>>> addition to your existing codebase, and your existing codebase 
>>>> is RSA_PKCS#1v1.5, then that is what you will do.
>>>  
>>> That would make sense only if your code base implements PKCS#1v1.5
>>> properly, and the chances for that are slim to none.
>>>  
>>> The list on Marvin Attack page is over 30 implementations long
>>> _because I tested just over 30 implementations._ Of all the ones
>>> tested only two turned out to be side-channel safe.
>>>  
>>> People's efforts are far better spent making sure that OAEP 
>>> is implemented
>>> correctly than wrangling PKCS#1v1.5 to make it side-channel free.
>>> Implementing OAEP from scratch will be easier than implementing
>>> PKCS#1v1.5 in side-channel free way.
>>>  
>>>> I suppose it is one possible outcome here for the IRTF / IETF 
>>>> to say that RSA-PKCS#1 and/or RSA-OAEP and/or RSA-KEM are 
>>>> deprecated and the IRTF / IETF will not be standardizing ML-KEM 
>>>> + RSA hybrids. That will not prevent people from doing it, it 
>>>> will just prevent people from doing it in standardized and 
>>>> peer-reviewed ways.
>>>  
>>> If we don't provide OIDs for combined PKCS#1/Kyber, then people won't
>>> be using it.
>>>   
>>>> ---
>>>> Mike Ounsworth
>>>>  
>>>> From: Watson Ladd <[e-mail]> 
>>>> Sent: Tuesday, February 20, 2024 3:15 PM
>>>> To: Mike Ounsworth <[e-mail]>
>>>> Cc: CFRG <[e-mail]>
>>>> Subject: Re: [EXTERNAL] [CFRG] What I want from the "KEM hybrids"
>>>>  
>>>> On Tue, Feb 20, 2024, 1: 06 PM Mike Ounsworth 
>>>> <Mike. Ounsworth@ entrust. com> wrote: > > Hey Watson, > > > > I 
>>>> could come around to this viewpoint that CFRG should not 
>>>> standardize a generic KEM combiner, but instead publish
>>>> On Tue, Feb 20, 2024, 1:06 PM Mike Ounsworth 
>>>> <[e-mail]> wrote:
>>>>> 
>>>>> Hey Watson,
>>>>> 
>>>>> 
>>>>> 
>>>>> I could come around to this viewpoint that CFRG should not 
>>>>> standardize a generic KEM combiner, but instead publish a suite 
>>>>> of specific-algorithm combiners.
>>>>> 
>>>>> 
>>>>> 
>>>>> The question then becomes: “which algorithms need to be 
>>>>> supported on the Internet during the PQC migration period?”  
>>>>> The answer is probably some subset of  {ML-KEM, NTRU, Classic 
>>>>> McEliece} X {X25519, X448, ECDH{P*, Brainpool*}, RSA-KEM, 
>>>>> RSA-PKCS#1, RSA-OAEP}. Then we get into the game of trying to 
>>>>> figure out which of those combinations have enough usage to 
>>>>> motivate their own spec.
>>>>  
>>>>  
>>>> I'm not convinced we need any RSA options. You shouldn't reuse key
>>>> material for this.
>>>>  
>>>> Why Brainpool? It's not deployed widely. ECDHP makes sense for
>>>> FedRAMP/FIPS issues but I won't cry if we say X25519 alone because
>>>> that is permitted now even if certificates aren't quite updated. There
>>>> needs to be a strong rationale for each additional variation, because
>>>> the more you fill out the cartesian product the more tempting a
>>>> generic interface that application users will misuse becomes.
>>>>  
>>>>> 
>>>>> 
>>>>> 
>>>>> The alternative is that CFRG publish a few optimized 
>>>>> combinations, like ML-KEM+x25519, and a lower-performance 
>>>>> generic combiner for “the rest”.
>>>>  
>>>> There is no generic interface here: RSA-OAEP, ECDH, are different in
>>>> ways that matter for security.
>>>>  
>>>> Sincerely,
>>>> Watson
>>>  
>>  
>  

-- 
Regards,
Hubert 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