[CFRG] Re: I-D Action: draft-irtf-cfrg-rsa-guidance-01.txt

[Alicja Kario <[e-mail]>]

On Friday, 6 September 2024 16:14:27 CEST, Riad S. Wahby wrote:
> Hello Alicja,
>
> Thanks for your message. I completely understand your position, so I guess
> at this point I'm just advocating for the devil. But here goes, in reverse
> order:
>
> Alicja Kario <[e-mail]> wrote:
>> Also, RFC 8017 says nothing about how to generate the RSA parameters.
>> 
>> So, I consider key generation out of scope.
>> See https://github.com/tomato42/marvin-ietf/pull/new/outside-scope
>> for the proposed text.
>
> This text is strictly true but also pretty unhelpful to the reader.
>
> Reader thinks: "But I need to generate keys... so what do I do now?"
>
> It seems like at the very least it makes sense to recommend generating keys
> on a system that is safely hidden from prying eyes. And perhaps in this
> context that's enough---even if it still seems like a missed opportunity
> to help the reader by at least waving in the directin of countermeasures!
>
>> The protections I talk in the Draft are for remote timing attacks,
>> potentially conducted even over the Internet.
>> 
>> How do you perform a remote network based attack against RSA 
>> key generation?
>
> This question is hard to answer in part because answering "how" requires
> knowing details of the system being attacked. I don't have those details.
>
> But if you're asking, does there exist a system in which RSA key generation
> can be attacked remotely via timing, my guess is very much yes: at this
> point it seems prudent just to assume that remote timing attacks are always
> practical in the absence of countermeasures. That's an over-approximation,
> but recent history suggests it's not all that far off.

And I'm going to say that the answer is "no".

Because simple timing attacks require you to measure the same operation
on the same secret values. If you have a situation where the attacker can
force you to generate private keys with the same RNG seed values you
have much bigger issues than side channel attacks.

So, just like Raccoon attack is impossible against server that uses 
ephemeral
key shares, remote timing attacks against RSA key gen that uses actual
entropy is not possible.

If you have a system that simply transmits in EM spectrum values
of the registers before operating on them, then there's literally nothing
we can do to protect against an attacker that can read the EM spectrum.
But that's not the typical system and that's not the typical attacker.
This is not a guide for designing TEMPEST hardened solutions.

So, please, let's focus on realistic scenarios, and not go into the weeds:
don't let the perfect be the enemy of the good.

> Or, putting on my Captain Obvious hat: "we've taken steps to prevent X"
> is always preferred to "we can't imagine how an attacker will do X".
>
> I'll end my devil's advocacy here. And: thank you for doing the hard work
> of writing down these valuable recommendations---please don't mistake
> my free-floating anxiety for a failure to appreciate your efforts!

OK, I'll take it as the PR https://github.com/tomato42/marvin-ietf/pull/3
being good enough.
-- 
Regards,
Alicja (nee 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