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

[Hubert Kario <[e-mail]>]

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