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

[Andrey Bozhko <[e-mail]>]

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
>
> ------------------------------
>
> * Intel Technology Poland sp. z o.o. * ul. Słowackiego 173 | 80-298
> Gdańsk | Sąd Rejonowy Gdańsk Północ | VII Wydział Gospodarczy Krajowego
> Rejestru Sądowego - KRS 101882 | NIP 957-07-52-316 | Kapitał zakładowy
> 200.000 PLN.
> Spółka oświadcza, że posiada status dużego przedsiębiorcy w rozumieniu
> ustawy z dnia 8 marca 2013 r. o przeciwdziałaniu nadmiernym opóźnieniom w
> transakcjach handlowych.
>
> Ta wiadomość wraz z załącznikami jest przeznaczona dla określonego
> adresata i może zawierać informacje poufne. W razie przypadkowego
> otrzymania tej wiadomości, prosimy o powiadomienie nadawcy oraz trwałe jej
> usunięcie; jakiekolwiek przeglądanie lub rozpowszechnianie jest zabronione.
> This e-mail and any attachments may contain confidential material for the
> sole use of the intended recipient(s). If you are not the intended
> recipient, please contact the sender and delete all copies; any review or
> distribution by others is strictly prohibited.
>
>