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

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

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. Slowackiego 173, 80-298 Gdansk - KRS 101882 - NIP 957-07-52-316

From: CFRG <[e-mail]> On Behalf Of Andrey Bozhko
Sent: Friday, March 29, 2024 10:24
To: Tereschenko, Aleksandr V <[e-mail]>
Cc: CFRG <[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 <[e-mail]<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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Stanislav V. Smyshlyaev
Sent: Tuesday, March 5, 2024 09:44
To: CFRG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [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 ([e-mail]<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