[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfrg
Subject:    Re: [CFRG] RGLC on draft-irtf-cfrg-aead-properties-04
From:       Andrey Bozhko <andbogc () gmail ! com>
Date:       2024-03-31 11:01:38
Message-ID: CAMd8_Zo3HVerks47DikkxMTK=3rT-yCxoJVafGCKAxTcLJEc5Q () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


>>> 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 <
aleksandr.v.tereschenko@intel.com> 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 <cfrg-bounces@irtf.org> *On Behalf Of * Andrey Bozhko
> *Sent:* Friday, March 29, 2024 10:24
> *To:* Tereschenko, Aleksandr V <aleksandr.v.tereschenko@intel.com>
> *Cc:* CFRG <cfrg@irtf.org>
> *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 <
> aleksandr.v.tereschenko@intel.com> 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 <cfrg-bounces@irtf.org> *On Behalf Of *Stanislav V.
> Smyshlyaev
> *Sent:* Tuesday, March 5, 2024 09:44
> *To:* CFRG <cfrg@irtf.org>
> *Cc:* cfrg-chairs@ietf.org; draft-irtf-cfrg-aead-properties@ietf.org
> *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 (cfrg-chairs@ietf.org). 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
>
>

[Attachment #5 (text/html)]

<div dir="auto"><div dir="auto"><span \
style="font-family:verdana,sans-serif;font-size:16px;font-style:normal;font-weight:400 \
;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spa \
cing:0px;text-decoration:none;float:none;display:inline!important;color:rgb(0,0,0)">&gt;&gt;&gt; \
maybe a short note would still be helpful then</span></div>  </div><div \
dir="auto"><span style="font-family:söhne,ui-sans-serif,system-ui,-apple-system,&quot;segoe \
ui&quot;,roboto,ubuntu,cantarell,&quot;noto sans&quot;,sans-serif,&quot;helvetica \
neue&quot;,arial,&quot;apple color emoji&quot;,&quot;segoe ui emoji&quot;,&quot;segoe \
ui symbol&quot;,&quot;noto color \
emoji&quot;;white-space:pre-wrap;border-color:rgb(227,227,227);color:rgb(13,13,13)">Sure! \
I completely agree with you on that. I&#39;ll make the corresponding changes and \
publish the updated version within 1-2 days.</span></div><div><p style="border:0px \
solid rgb(227,227,227);margin:1.25em \
0px;font-family:söhne,ui-sans-serif,system-ui,-apple-system,&quot;segoe \
ui&quot;,roboto,ubuntu,cantarell,&quot;noto sans&quot;,sans-serif,&quot;helvetica \
neue&quot;,arial,&quot;apple color emoji&quot;,&quot;segoe ui emoji&quot;,&quot;segoe \
ui symbol&quot;,&quot;noto color \
emoji&quot;;font-size:16px;font-style:normal;font-weight:400;letter-spacing:normal;tex \
t-indent:0px;text-transform:none;white-space:pre-wrap;word-spacing:0px;text-decoration:none;color:rgb(13,13,13)" \
dir="auto">Thanks for the discussion!</p></div><div dir="auto">Regards,  </div><div \
dir="auto">Andrey</div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div \
dir="ltr" class="gmail_attr">On Sat, 30 Mar 2024 at 01:19 Tereschenko, Aleksandr V \
&lt;<a href="mailto:aleksandr.v.tereschenko@intel.com">aleksandr.v.tereschenko@intel.com</a>&gt; \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">






<div lang="EN-US" link="blue" vlink="purple" style="overflow-wrap: break-word;">
<div class="m_1341511625982566074WordSection1">
<p class="MsoNormal"><span style="font-family:Verdana,sans-serif">Thanks Andrey, both \
make sense to me.<u style="font-family:Verdana,sans-serif"></u><u \
style="font-family:Verdana,sans-serif"></u></span></p> <p class="MsoNormal"><span \
style="font-family:Verdana,sans-serif"><u style="font-family:Verdana,sans-serif"></u> \
<u style="font-family:Verdana,sans-serif"></u></span></p> <p class="MsoNormal"><span \
style="font-family:Verdana,sans-serif">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&#39;s head)? A condensed version  of your \
clarification below would work perfectly I think, e.g., something along the lines of: \
&quot;<i style="font-family:Verdana,sans-serif">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</i>&quot;.<u \
style="font-family:Verdana,sans-serif"></u><u \
style="font-family:Verdana,sans-serif"></u></span></p> <p class="MsoNormal"><span \
style="font-family:Verdana,sans-serif"><u style="font-family:Verdana,sans-serif"></u> \
<u style="font-family:Verdana,sans-serif"></u></span></p> <p class="MsoNormal"><span \
style="font-family:Verdana,sans-serif">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).<u style="font-family:Verdana,sans-serif"></u><u \
style="font-family:Verdana,sans-serif"></u></span></p> <p class="MsoNormal"><span \
style="font-family:Verdana,sans-serif"><u style="font-family:Verdana,sans-serif"></u> \
<u style="font-family:Verdana,sans-serif"></u></span></p> <p class="MsoNormal"><span \
style="font-family:Verdana,sans-serif">It would also be a nod to what Bellizia et al. \
mention about that notion: &quot;<i style="font-family:Verdana,sans-serif">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</i>&quot;.<u \
style="font-family:Verdana,sans-serif"></u><u \
style="font-family:Verdana,sans-serif"></u></span></p> <p class="MsoNormal"><span \
style="font-family:Verdana,sans-serif"><u style="font-family:Verdana,sans-serif"></u> \
<u style="font-family:Verdana,sans-serif"></u></span></p> <p class="MsoNormal"><span \
style="font-family:Verdana,sans-serif">Either way, kudos for a nice document!<u \
style="font-family:Verdana,sans-serif"></u><u \
style="font-family:Verdana,sans-serif"></u></span></p> <p class="MsoNormal"><span \
style="font-family:Verdana,sans-serif;color:rgb(31,56,100)"><u \
style="font-family:Verdana,sans-serif"></u>  <u \
style="font-family:Verdana,sans-serif"></u></span></p> <p class="MsoNormal"><span \
style="font-family:Verdana,sans-serif">regards,<u \
style="font-family:Verdana,sans-serif"></u><u \
style="font-family:Verdana,sans-serif"></u></span></p> <p class="MsoNormal"><span \
style="font-family:Verdana,sans-serif">Alexander Tereschenko (he/him)<u \
style="font-family:Verdana,sans-serif"></u><u \
style="font-family:Verdana,sans-serif"></u></span></p> <p class="MsoNormal"><span \
style="font-family:Verdana,sans-serif">Intel Product Assurance and Security (IPAS) \
Crypto Team<u style="font-family:Verdana,sans-serif"></u><u \
style="font-family:Verdana,sans-serif"></u></span></p> <p class="MsoNormal"><span \
lang="PL" style="font-family:Verdana,sans-serif">-------------------------------------------------------------<u \
style="font-family:Verdana,sans-serif"></u><u \
style="font-family:Verdana,sans-serif"></u></span></p> <p class="MsoNormal"><span \
lang="PL" style="font-size:10pt;font-family:Verdana,sans-serif;color:rgb(32,33,34)">Intel \
Technology Poland sp. z o.o. - ul. </span><span \
style="font-size:10pt;font-family:Verdana,sans-serif;color:rgb(32,33,34)"><a \
href="https://www.google.com/maps/search/Slowackiego+173,+80-298+Gdansk?entry=gmail&amp;source=g" \
style="font-family:Verdana,sans-serif">Slowackiego 173, 80-298 Gdansk</a> - KRS \
101882 - NIP 957-07-52-316</span><span \
style="font-size:10pt;font-family:Verdana,sans-serif"><u \
style="font-family:Verdana,sans-serif"></u><u \
style="font-family:Verdana,sans-serif"></u></span></p> <p class="MsoNormal"><span \
style="font-family:Verdana,sans-serif;color:rgb(31,56,100)"><u \
style="font-family:Verdana,sans-serif"></u>  <u \
style="font-family:Verdana,sans-serif"></u></span></p> <div style="border-width:1pt \
medium medium;border-style:solid none none;padding:3pt 0cm \
0cm;border-color:rgb(225,225,225) currentcolor currentcolor"> <p \
class="MsoNormal"><b>From:</b> CFRG &lt;<a href="mailto:cfrg-bounces@irtf.org" \
target="_blank">cfrg-bounces@irtf.org</a>&gt; <b>On Behalf Of </b> Andrey Bozhko<br>
<b>Sent:</b> Friday, March 29, 2024 10:24<br>
<b>To:</b> Tereschenko, Aleksandr V &lt;<a \
href="mailto:aleksandr.v.tereschenko@intel.com" \
target="_blank">aleksandr.v.tereschenko@intel.com</a>&gt;<br> <b>Cc:</b> CFRG &lt;<a \
href="mailto:cfrg@irtf.org" target="_blank">cfrg@irtf.org</a>&gt;<br> <b>Subject:</b> \
Re: [CFRG] RGLC on draft-irtf-cfrg-aead-properties-04<u></u><u></u></p> </div>
<p class="MsoNormal"><u></u>  <u></u></p>
<div>
<div>
<p class="MsoNormal">Hi Alexander,<u></u><u></u></p>
</div></div></div></div><div lang="EN-US" link="blue" vlink="purple" \
style="overflow-wrap: break-word;"><div \
class="m_1341511625982566074WordSection1"><div> <div>
<p class="MsoNormal"><u></u>  <u></u></p>
</div>
<div>
<p class="MsoNormal">Thank you for the review and very interesting comments! Please \
find some answers and explanations below.<u></u><u></u></p> </div>
<div>
<p class="MsoNormal"><u></u>  <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p> </div>
<div>
<p class="MsoNormal"><u></u>  <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u>  <u></u></p>
</div>
<div>
<p class="MsoNormal">[1] Barwell, G., et al., "Authenticated encryption in the face \
of protocol and side channel leakage", <a href="https://eprint.iacr.org/2017/068.pdf" \
target="_blank">https://eprint.iacr.org/2017/068.pdf</a>  <u></u><u></u></p> </div>
<div>
<p class="MsoNormal"><u></u>  <u></u></p>
</div>
<div>
<p class="MsoNormal">[2] Guo, C., et al., &quot;Authenticated Encryption with Nonce \
Misuse and Physical Leakages: Definitions, Separation Results and Leveled \
Constructions&quot;, <a \
href="https://link.springer.com/chapter/10.1007/978-3-030-30530-7_8" \
target="_blank">https://link.springer.com/chapter/10.1007/978-3-030-30530-7_8</a>  \
<u></u><u></u></p> </div>
<div>
<p class="MsoNormal"><u></u>  <u></u></p>
</div>
<div>
<p class="MsoNormal">[3] Bellizia, D., et al., &quot;Mode-Level vs. \
Implementation-Level Physical Security in Symmetric Cryptography: A Practical Guide \
Through the Leakage-Resistance Jungle&quot;, <a \
href="https://link.springer.com/chapter/10.1007/978-3-030-56784-2_13" \
target="_blank">https://link.springer.com/chapter/10.1007/978-3-030-56784-2_13</a><u></u><u></u></p>
 </div>
<p class="MsoNormal"><u></u>  <u></u></p>
</div>
<div>
<p class="MsoNormal">Regards,  <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Andrey<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u>  <u></u></p>
<div>
<div>
<p class="MsoNormal">On Thu, 28 Mar 2024 at 20:26 Tereschenko, Aleksandr V &lt;<a \
href="mailto:aleksandr.v.tereschenko@intel.com" \
target="_blank">aleksandr.v.tereschenko@intel.com</a>&gt; wrote:<u></u><u></u></p> \
</div> <blockquote style="border-width:medium medium medium 1pt;border-style:none \
none none solid;padding:0cm 0cm 0cm \
6pt;margin-left:4.8pt;margin-right:0cm;border-color:currentcolor currentcolor \
currentcolor rgb(204,204,204)"> <div>
<div>
<p class="MsoNormal"><span style="font-family:Verdana,sans-serif">Hello \
everyone,</span><u></u><u></u></p> <p class="MsoNormal"><span \
style="font-family:Verdana,sans-serif">  </span><u></u><u></u></p> <p \
class="MsoNormal"><span style="font-family:Verdana,sans-serif">Apologies for slightly \
missing the formal RGLC deadline, hopefully this feedback is still useful. I&#39;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&#39;s primary goal laudable.</span><u></u><u></u></p> <p \
class="MsoNormal"><span style="font-family:Verdana,sans-serif">  \
</span><u></u><u></u></p> <p class="MsoNormal"><span \
style="font-family:Verdana,sans-serif">I also have a couple of minor comments, listed \
in no particular order below.</span><u></u><u></u></p> <p class="MsoNormal"><span \
style="font-family:Verdana,sans-serif;color:rgb(31,56,100)">  \
</span><u></u><u></u></p> <ol start="1" type="1">
<li class="MsoNormal" style="vertical-align:middle">
<span style="font-family:Verdana,sans-serif">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&#39;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 &quot;&lt;…&gt; provides security (resilience \
or resistance) &lt;…&gt;&quot; to the main definition, and then definitions of both \
resilience and resistance as sub-items under it.</span><u></u><u></u></li><li \
class="MsoNormal" style="vertical-align:middle"> <span \
style="font-family:Verdana,sans-serif">Section 4.3.5. Multi-User Security: as shown \
in the referenced BT16 paper and as it authors emphasize, there&#39;s also a \
potentially distinct and relevant &quot;mu kr&quot; notion in addition to the \
&quot;mu ind&quot; one, maybe it&#39;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.</span><u></u><u></u></li><li class="MsoNormal" \
style="vertical-align:middle"> <span style="font-family:Verdana,sans-serif">Typo: \
&quot;commiting&quot; -&gt; &quot;committing&quot; (Section 4.3.2 &quot;Examples: \
&lt;…&gt;&quot;)</span><u></u><u></u></li><li class="MsoNormal" \
style="vertical-align:middle"> <span style="font-family:Verdana,sans-serif">Typo: \
&quot;i.e,&quot; -&gt; &quot;i.e.,&quot; (Section 4.3.8 &quot;Q2 model: \
&lt;…&gt;&quot;)</span><u></u><u></u></li></ol> <p class="MsoNormal"><span \
style="font-family:Verdana,sans-serif;color:rgb(31,56,100)">  \
</span><u></u><u></u></p> <p class="MsoNormal"><span \
style="font-family:Verdana,sans-serif;color:rgb(31,56,100)">[1] </span><span \
style="font-family:Verdana,sans-serif"><a \
href="https://link.springer.com/chapter/10.1007/978-3-030-56784-2_13" target="_blank" \
style="font-family:Verdana,sans-serif">https://link.springer.com/chapter/10.1007/978-3-030-56784-2_13</a></span><u></u><u></u></p>
 <p class="MsoNormal"><span style="font-family:Verdana,sans-serif">[2]
<a href="https://link.springer.com/chapter/10.1007/978-3-030-30530-7_8" \
target="_blank" style="font-family:Verdana,sans-serif"> \
https://link.springer.com/chapter/10.1007/978-3-030-30530-7_8</a></span><u></u><u></u></p>
 <p class="MsoNormal"><span \
style="font-family:Verdana,sans-serif;color:rgb(31,56,100)">  \
</span><u></u><u></u></p> <p class="MsoNormal"><span \
style="font-family:Verdana,sans-serif">regards,</span><u></u><u></u></p> <p \
class="MsoNormal"><span style="font-family:Verdana,sans-serif">Alexander Tereschenko \
(he/him)</span><u></u><u></u></p> <p class="MsoNormal"><span \
style="font-family:Verdana,sans-serif">Intel Product Assurance and Security (IPAS) \
Crypto Team</span><u></u><u></u></p> </div>
</div>
<div>
<div>
<p class="MsoNormal"><span \
style="font-family:Verdana,sans-serif;color:rgb(31,56,100)">  \
</span><u></u><u></u></p> <div style="border-width:1pt medium \
medium;border-style:solid none none;padding:3pt 0cm 0cm;border-color:currentcolor"> \
<p class="MsoNormal"><b>From:</b> CFRG &lt;<a href="mailto:cfrg-bounces@irtf.org" \
target="_blank">cfrg-bounces@irtf.org</a>&gt; <b>On Behalf Of </b>Stanislav V. \
Smyshlyaev<br> <b>Sent:</b> Tuesday, March 5, 2024 09:44<br>
<b>To:</b> CFRG &lt;<a href="mailto:cfrg@irtf.org" \
target="_blank">cfrg@irtf.org</a>&gt;<br> <b>Cc:</b> <a \
href="mailto:cfrg-chairs@ietf.org" target="_blank">cfrg-chairs@ietf.org</a>; <a \
href="mailto:draft-irtf-cfrg-aead-properties@ietf.org" \
target="_blank">draft-irtf-cfrg-aead-properties@ietf.org</a><br> <b>Subject:</b> \
[CFRG] RGLC on draft-irtf-cfrg-aead-properties-04<u></u><u></u></p> </div>
<p class="MsoNormal">  <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">Dear  CFRG  participants,<br>
<br>
This message is starting 3 weeks  <span \
class="m_1341511625982566074m-4490955181926481731gmail-il">RGLC</span>  on \
draft-irtf-cfrg-aead-properties-04  (&quot;Properties of AEAD Algorithms&quot;)  that \
will end  on  March 26th 2024. If you&#39;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 (<a href="mailto:cfrg-chairs@ietf.org" \
target="_blank">cfrg-chairs@ietf.org</a>). If you have detailed comments, these would \
also be very helpful at this  point.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">  <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">We&#39;ve got a review of the draft by Russ Housley (on behalf \
of the Crypto Review Panel):  <a \
href="https://mailarchive.ietf.org/arch/msg/crypto-panel/aNQc4kc0DFlSPy_ohUttM4QEVXc/" \
target="_blank">https://mailarchive.ietf.org/arch/msg/crypto-panel/aNQc4kc0DFlSPy_ohUttM4QEVXc/</a><u></u><u></u></p>
 </div>
<div>
<p class="MsoNormal">Russ has confirmed that his comments have been \
addressed.<u></u><u></u></p> </div>
<div>
<p class="MsoNormal">  <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Thank you,<u></u><u></u></p>
</div>
<p class="MsoNormal">Stanislav, for  CFRG  chairs<span \
style="font-size:8pt;font-family:&quot;Arial \
Narrow&quot;,sans-serif;color:rgb(89,89,89)"> </span><u></u><u></u></p>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>

</blockquote></div></div>



_______________________________________________
CFRG mailing list
CFRG@irtf.org
https://mailman.irtf.org/mailman/listinfo/cfrg


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic