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

[Alicja Kario <[e-mail]>]

On Friday, 26 June 2026 20:43:22 CEST, Michael StJohns wrote:
> Two more suggested changes in the same vein:
>
> In the abstract:
> s/This document specifies additions to RFC 8017. Specifically, 
> it provides/This document supplements RFC 8017 by providing/
>
> In the security considerations - instead of what's there 
> (including "specifies"):
>
> "The entirety of this document provides guidance for the secure 
> implementation of the RSA standards and algorithms."
>
> And a quick scan through:
>
> 1 - second para: "Protections against them" - sightly 
> ambiguous.  Instead "Protections against such attacks"
>
> Section 6 - somewhat inconsistent use of SHOULD/should and 
> MUST/must - suggest a pass to review.  AIRC, the use of BCP14 
> language is disfavored in non-standards.  At most what this 
> document is doing is making suggestions for the implementer (who 
> may or may not have other requirements to meet) rather than 
> imposing requirements, so lower-casing all of these and removing 
> section 3 may be appropriate.

I would say that the MUST in 5th paragraph of Section 5:
"...the algorithm MUST be implemented as stated..." is necessary,
so I'm strongly opposed to dropping BDP14 language in entirety.

Fair point on the inconsistent use though. Will try to address it tomorrow.

> Section 6 - power based  side channels attacks aren't mentioned 
> in this section at all, and there may be design tradeoffs 
> between memory, power, processing etc.  A paragraph (e.g. more 
> than a throwaway note in section 5 and in section 9.1) 
> indicating the limitations of this discussion with respect to 
> other side channels not fully discussed/developed here may be 
> appropriate.
>
> General - I see not a single mention of existing testing 
> regimes, and what they miss/might miss without these 
> improvements.  And a few brief notes on how effective these 
> mitigation techniques might be against machine-learning based 
> SCA might also be useful.

I'll answer both of those paragraphs together.

The big issue is that it depends on multiple things:
 - the leakage of the hardware in question
 - assumed capabilities of the attacker
 - no "gold standard" for side-channel analysis the same way we have for
   timing

Some of those operations (like blinding) are just defence in depth (if the
whole modular exponentation is side-channel free then it's not necessary,
OTOH, if it is leaky with respect to the base, then that is an easy fix
for it).

For timing side-channels we do have the "Traditional Constant Time
Model" (as defined by https://arxiv.org/pdf/2606.13000) that can be
summed up as "no secret-dependent branches, no secret-dependent memory
address location accesses, and no instructions with secret-dependent 
timing".
That is achievable in practice on commodity hardware (x86_64, aarch64,
ppc64,...)

The problem is that for more physical side channels, like power, EM, etc.
the typical platforms that need this kind of protections use very simple
hardware (microcontrollers, not full-fledged microarchitectures) that may 
not
even have a timing-side-channel free multiplication unit
(*cough*Cortex M4*cough*).

Then we have the issue that the dominant assesment method (TVLA) is
so flawed that you can write papers just on ways that it fails:
https://pdfs.semanticscholar.org/e518/a72553adbae0df971c8e13a7fc5c68461662.pdf

Generally, testing for side-channels is a *mess* and thus the typical
countermeasures are also rather bad (target specific attack method, not 
leak
in general).

But I don't think this is a fight that a CFRG document should contribute
at this point.

> Overall, a useful document and fairly easy to understand.

Thank you!

> Mike
>
>
>
>
>
> On 6/26/2026 12:16, Alicja Kario wrote:
>> Document was updated to make it clear that it's the consensus of CFRG, not
>> a IETF standard.
>> 
>> On Friday, 26 June 2026 18:11:20 CEST, [e-mail] wrote: ...
>

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