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

[Michael StJohns <[e-mail]>]

Hi -

See my comments at the repo.  Nits which you can fix or not.   Thanks 
for the changes.

Mike


On 7/2/2026 12:37, Alicja Kario wrote:
> On Monday, 29 June 2026 21:09:27 CEST, Michael StJohns wrote:
>> Hi Alicja - inline.
>>
>> On 6/29/2026 14:40, Alicja Kario wrote:
>>> On Friday, 26 June 2026 20:43:22 CEST, Michael StJohns wrote:
>>>>
>>>> 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.
>>
>> -09 that language seems to be in section 7 para 5. - same thing? By 
>> the way *which* algorithm are you referring to here as "the 
>> algorithm"?  OAEP, PKCS1v1.5, general RSA, implicit rejection?
>
> Implicit rejection. I'd say it's clear in the wider context...
>
>> *bleah*  Things like CFRG documents with BCP language are reasons I 
>> wish that the CFRG were either a WG or co-chartered as a WG.
>>
>> Have you considered asking the SEC ADs to sponsor and authorize 
>> publication of this as a BCP on the IETF side?
>
> I'd rather not... It's been a draft for almost 3 years at this point,
> I just want it published...
>
>>>
>>>> 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
>>>
>>> <stuff deleted - just to make this more readable>
>>
>> I think I agree with all of what you wrote here.  What I was looking 
>> for though was simply a hint to the reader that other considerations 
>> may apply and that techniques such as DPA may require mitigations 
>> past what the document provides.  On the testing side... yeah.. its 
>> hard.  Maybe being up front that even these techniques might not 
>> mitigate testing flaws.
>>
>> The last one - Machine Learning SCAs... always useful to mention the 
>> attack/defense arms race and to exhort the implementers to not become 
>> complacent.
>
> Included both changes in the 
> https://github.com/tomato42/marvin-ietf/pull/11