Re: [CFRG] RGLC on draft-irtf-cfrg-aead-properties-04

["Tereschenko, Aleksandr V" <[e-mail]>]

(Looks like this email thread got too big for the mail list limitations and my reply seems to have been stuck in moderation, let me try a plaintext version + Andrey's email directly for robustness. Apologies for any duplicates!)


Thank you too, and just for the record, I-D draft version -06 recently published does address all my comments, great job!

Regards,
Alexander Tereschenko (he/him)
Intel Product Assurance and Security (IPAS) Crypto Team
-------------------------------------------------------------
Intel Technology Poland sp. z o.o. - ul. Slowackiego 173, 80-298 Gdansk - KRS 101882 - NIP 957-07-52-316

---------------------------------------------------------------------------------------------------------------------------------------------------

From: Andrey Bozhko <[e-mail]> 
Sent: Sunday, March 31, 2024 13:02
To: Tereschenko, Aleksandr V <[e-mail]>
Cc: CFRG <[e-mail]>
Subject: Re: [CFRG] RGLC on draft-irtf-cfrg-aead-properties-04

>>> maybe a short note would still be helpful then
 
Sure! I completely agree with you on that. I'll make the corresponding changes and publish the updated version within 1-2 days.
Thanks for the discussion!
Regards, 
Andrey

On Sat, 30 Mar 2024 at 01:19 Tereschenko, Aleksandr V <mailto:[e-mail]> wrote:
Thanks Andrey, both make sense to me.
 
For #1, maybe a short note would still be helpful then, to acknowledge its existence and avoid this same question being raised later on (or popping up in reader's head)? A condensed version of your clarification below would work perfectly I think, e.g., something along the lines of: "There is also a well-known weaker notion - Leakage Resilience, but this document makes a conscious choice to focus on a stronger Leakage Resistance one, following the framework established in [Guo et al., Bellizia et al.], for its better practicality and comprehensiveness".
 
This is just to aim the reader with necessary references, should they need to dig deeper (in the spirit of the I-D) + address the potential question (which, given the widespread use of the term may be quite natural).
 
It would also be a nod to what Bellizia et al. mention about that notion: "We insist that this observation does not invalidate the interest of the leakage-resilience setting: whether (stronger) leakage-resistance or (weaker) leakage-resilience is needed depends on application constraints".
 
Either way, kudos for a nice document!
 
regards,
Alexander Tereschenko (he/him)
Intel Product Assurance and Security (IPAS) Crypto Team
-------------------------------------------------------------
Intel Technology Poland sp. z o.o. - ul. https://www.google.com/maps/search/Slowackiego+173,+80-298+Gdansk?entry=gmail&source=g - KRS 101882 - NIP 957-07-52-316
 
From: CFRG <mailto:[e-mail]> On Behalf Of Andrey Bozhko
Sent: Friday, March 29, 2024 10:24
To: Tereschenko, Aleksandr V <mailto:[e-mail]>
Cc: CFRG <mailto:[e-mail]>
Subject: Re: [CFRG] RGLC on draft-irtf-cfrg-aead-properties-04
 
Hi Alexander,
 
Thank you for the review and very interesting comments! Please find some answers and explanations below.
 
1. I considered adding resilience in the sense of [1] when writing that section as well. However, after discussions with reviewers of earlier versions, it was decided to only leave resistance following the [2,3] line of work. The main reason here was that the framework of [2,3] is better developed, allows for comprehensive and intuitive analysis, and is tailored for real-life schemes. Another reason is that initial papers in which resilience and resistance were introduced consider different leakage models (e.g., partial and full leakages). Explaining these differences in the draft would have led to introducing confusion rather than reducing it. So, it was more or less a weighted decision to focus only on leakage resistance in the draft.
 
2. Indeed, that would be nice. I will add a corresponding sentence to the “Note” paragraph in the mu security section. However, I think it is reasonable to only mention indistinguishability as a targeted security notion in the “Security notion” paragraph.
 
[1] Barwell, G., et al., “Authenticated encryption in the face of protocol and side channel leakage”, https://eprint.iacr.org/2017/068.pdf 
 
[2] Guo, C., et al., "Authenticated Encryption with Nonce Misuse and Physical Leakages: Definitions, Separation Results and Leveled Constructions", https://link.springer.com/chapter/10.1007/978-3-030-30530-7_8 
 
[3] Bellizia, D., et al., "Mode-Level vs. Implementation-Level Physical Security in Symmetric Cryptography: A Practical Guide Through the Leakage-Resistance Jungle", https://link.springer.com/chapter/10.1007/978-3-030-56784-2_13
 
Regards, 
Andrey
 
On Thu, 28 Mar 2024 at 20:26 Tereschenko, Aleksandr V <mailto:[e-mail]> wrote:
Hello everyone,
 
Apologies for slightly missing the formal RGLC deadline, hopefully this feedback is still useful. I've reviewed the draft (version -05 though, but replying in this RGLC thread about -04 for continuity) and overall I think this is a useful document that is ready for publication. Establishing common language for complex things like those security and implementation properties is certainly helpful and should lead to fewer mistakes, i.e., better security, so I find the document's primary goal laudable.
 
I also have a couple of minor comments, listed in no particular order below.
 
1. Section 4.3.4 mentions leakage resistance without mentioning leakage *resilience*, which is a distinct and weaker notion also widely used (e.g., [1] or [2]). Given that, I'd suggest mentioning it as well, by e.g., following the approach used in section 4.3.7. Nonce Misuse and adding resilience-related text like "<…> provides security (resilience or resistance) <…>" to the main definition, and then definitions of both resilience and resistance as sub-items under it.
2. Section 4.3.5. Multi-User Security: as shown in the referenced BT16 paper and as it authors emphasize, there's also a potentially distinct and relevant "mu kr" notion in addition to the "mu ind" one, maybe it's worth mentioning too? I admit that unlike with the leakage resistance/resilience, this distinction does not seem to be widespread in other papers, so just wanted to bring that up for consideration, given the emphasis in the paper.
3. Typo: "commiting" -> "committing" (Section 4.3.2 "Examples: <…>")
4. Typo: "i.e," -> "i.e.," (Section 4.3.8 "Q2 model: <…>")
 
[1] https://link.springer.com/chapter/10.1007/978-3-030-56784-2_13
[2] https://link.springer.com/chapter/10.1007/978-3-030-30530-7_8
 
regards,
Alexander Tereschenko (he/him)
Intel Product Assurance and Security (IPAS) Crypto Team
 
From: CFRG <mailto:[e-mail]> On Behalf Of Stanislav V. Smyshlyaev
Sent: Tuesday, March 5, 2024 09:44
To: CFRG <mailto:[e-mail]>
Cc: mailto:[e-mail]; mailto:[e-mail]
Subject: [CFRG] RGLC on draft-irtf-cfrg-aead-properties-04
 
Dear CFRG participants,

This message is starting 3 weeks RGLC on draft-irtf-cfrg-aead-properties-04 ("Properties of AEAD Algorithms") that will end on March 26th 2024. If you've read the document and think that it is ready (or not ready) for publication as an RFC, please send a message in reply to this email or directly to CFRG chairs (mailto:[e-mail]). If you have detailed comments, these would also be very helpful at this point.
 
We've got a review of the draft by Russ Housley (on behalf of the Crypto Review Panel): https://mailarchive.ietf.org/arch/msg/crypto-panel/aNQc4kc0DFlSPy_ohUttM4QEVXc/
Russ has confirmed that his comments have been addressed.
 
Thank you,
Stanislav, for CFRG chairs