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

[Andrey Bozhko <[e-mail]>]

Hi all,

just for the record, I-D draft version -06 recently published does address
> all my comments


Alexander, thank you for the confirmation. I'm glad to hear that!

Stephen, could you please confirm if the latest version of the draft
addresses your concerns as well? Thank you in advance!

Regards,
Andrey


On Wed, Apr 3, 2024 at 5:49 PM Tereschenko, Aleksandr V <
[e-mail]> wrote:

> (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
>