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

[Andrey Bozhko <[e-mail]>]

>>> 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 <
[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. Slowackiego 173, 80-298 Gdansk
> <https://www.google.com/maps/search/Slowackiego+173,+80-298+Gdansk?entry=gmail&source=g>
> - 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]> 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]> *On Behalf Of *Stanislav V.
> Smyshlyaev
> *Sent:* Tuesday, March 5, 2024 09:44
> *To:* CFRG <[e-mail]>
> *Cc:* [e-mail]; [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]). 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
>
>