Author(s),
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the XML file.
1) <!-- [rfced] Please note that the title of the document has been updated as
follows. Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC
Style Guide"). Please review.
Original:
Properties of AEAD Algorithms
Current:
Properties of Authenticated Encryption with Associated Data (AEAD)
Algorithms
-->
2) <!-- [rfced] Please ensure that the guidelines listed in Section 2.1 of RFC
5743 have been adhered to in this document. See
https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1.
-->
3) <!-- [rfced] Will readers understand what "it" refers to here?
Original:
We note that specifications of AEAD algorithms that use
authentication tags to ensure integrity MAY define it as an
independent output of the encryption operation and as an independent
input of the decryption operation.
-->
4) <!-- [rfced] Please confirm that "IND-CTXT" is correct here. We ask because
we
do not see "IND-CTXT" in [BN2000], but we do see "INT-CTXT".
Original:
Security notion: IND-CTXT [BN2000] (or AUTH [R02]).
Security notion: IND-CPA and IND-CTXT [BN2000][R02] (or equivalently
IND-CCA3 [S04]).
-->
5) <!-- [rfced] May we remove "It holds that"?
Original:
It holds that for any AEAD algorithm security degrades no worse
than linearly with an increase in the number of users [BT16].
Perhaps:
For any AEAD algorithm, security degrades no worse
than linearly with an increase in the number of users [BT16].
-->
6) <!-- [rfced] Should "Hide-Nonce (HN)" be updated to "Nonce-Hiding" per the
title of Section 4.3.6? We are unable to access [BNT19] to check for
guidance there.
Original:
4.3.6. Nonce-Hiding
...
Examples: Hide-Nonce (HN) transforms [BNT19].
Perhaps:
4.3.6. Nonce Hiding
...
Examples: Nonce-hiding transforms [BNT19].
-->
7) <!-- [rfced] FYI - We made minor changes to the quoted text (lowercased "the"
and changed "beyond" to "besides") to exactly match the text at [A14].
Original:
In [A14], the notion of 'Plaintext
Awareness' is introduced, capturing the best possible
confidentiality under RUP in the following sense: 'The adversary
cannot gain any additional knowledge about the plaintext from
decryption queries beyond what it can derive from encryption
queries'.
-->
8) <!-- [rfced] How may we clarify "as should all trade-offs be"?
Original:
In an
application, the requirements for additional AEAD properties SHOULD
be highly motivated and justified, as should all trade-offs be
carefully considered.
Perhaps:
In an
application, the requirements for additional AEAD properties SHOULD
be highly motivated and justified, and all trade-offs should be
carefully considered.
Or:
In an
application, the requirements for additional AEAD properties SHOULD
be highly motivated and justified, as all trade-offs should be
carefully considered.
-->
9) <!-- [rfced] The URL in this reference entry points to a 2008 publication of
the paper, but the information in the reference entry is for a 2000
publication. Which would you like to cite?
2008 - https://doi.org/10.1007/s00145-008-9026-x
2000 - https://doi.org/10.1007/3-540-44448-3_41
Original:
[BN2000] Bellare, M. and C. Namprempre, "Authenticated Encryption:
Relations among Notions and Analysis of the Generic
Composition Paradigm", Proceedings of ASIACRYPT 2000,
Springer-Verlag, LNCS 1976, pp. 531-545,
DOI 10.1007/s00145-008-9026-x, 2000,
<https://doi.org/10.1007/s00145-008-9026-x>.
Perhaps (1) - 2000 paper:
[BN2000] Bellare, M. and C. Namprempre, "Authenticated Encryption:
Relations among Notions and Analysis of the Generic
Composition Paradigm", Advances in Cryptology - ASIACRYPT
2000, Lecture Notes in Computer Science, vol. 1976, pp.
531-545, DOI 10.1007/3-540-44448-3_41, 2000,
<https://doi.org/10.1007/3-540-44448-3_41>.
Perhaps (2) - 2008 paper:
[BN2000] Bellare, M. and C. Namprempre, "Authenticated Encryption:
Relations among Notions and Analysis of the Generic
Composition Paradigm", Journal of Cryptology, vol. 21,
pp. 469–491,
DOI 10.1007/s00145-008-9026-x, July 2008,
<https://doi.org/10.1007/s00145-008-9026-x>.
-->
10) <!-- [rfced] FYI - We updated the title in the reference entry to match the
title in the provided URL.
Original;
[GPPS19] Guo, C., Pereira, O., Peters, T., and FX. Standaert,
"Authenticated Encryption with Nonce Misuse and Physical
Leakages: Definitions, Separation Results and Leveled
Constructions", Progress in Cryptology - LATINCRYPT 2019.
LATINCRYPT 2019. Lecture Notes in Computer Science, vol
11774. Springer, Cham, DOI 10.1007/978-3-030-30530-7_8,
2019, <https://doi.org/10.1007/978-3-030-30530-7_8>.
Updated:
[GPPS19] Guo, C., Pereira, O., Peters, T., and F.-X. Standaert,
"Authenticated Encryption with Nonce Misuse and Physical
Leakages: Definitions, Separation Results and First
Construction", Progress in Cryptology - LATINCRYPT 2019,
Lecture Notes in Computer Science, vol. 11774, pp.
150-172, DOI 10.1007/978-3-030-30530-7_8, 2019,
<https://doi.org/10.1007/978-3-030-30530-7_8>.
-->
11) <!-- [rfced] FYI - Per the provided URL, the date for this reference is
"2017"
rather than "2016". We updated the reference entry accordingly and also
updated the citation tag from from "[EV16]" to "[EV17]".
Original:
[EV16] Endignoux, G. and D. Vizár, "Linking Online Misuse-
Resistant Authenticated Encryption and Blockwise Attack
Models", IACR Transactions on Symmetric Cryptology,
DOI 10.13154/TOSC.V2016.I2.125-144, 2016,
<https://doi.org/10.13154/TOSC.V2016.I2.125-144>.
Perhaps:
[EV17] Endignoux, G. and D. Vizár, "Linking Online Misuse-
Resistant Authenticated Encryption and Blockwise Attack
Models", IACR Transactions on Symmetric Cryptology, vol.
2016, no. 2, pp. 125-144,
DOI 10.13154/TOSC.V2016.I2.125-144, 2017,
<https://doi.org/10.13154/TOSC.V2016.I2.125-144>.
-->
12) <!-- [rfced] May we update this sentence for clarity?
Original:
An AEAD algorithm allows re-encrypting and authenticating a
message (associated data and a plaintext pair), which only partly
differs from some previous message, faster than processing it from
scratch.
Perhaps:
For a message that only partly differs from some previous message, an
AEAD algorithm allows re-encrypting and authenticating that
message (associated data and a plaintext pair) faster than processing it
from scratch.
-->
13) <!-- [rfced] We updated "Additional Functionality AEAD class" and
"Additional
Functionality AEAD algorithm" as follows. Please review.
Original:
Most importantly, for every Additional Functionality AEAD class,
conventional security properties must be redefined concerning the
targeted additional functionality and the new interface.
...
Although it
might be possible to consider a particular Additional Functionality
AEAD algorithm as a conventional AEAD algorithm ...
Updated:
Most importantly, for every AEAD class with additional functionality,
conventional security properties must be redefined concerning the
targeted additional functionality and the new interface.
...
Although it
might be possible to consider a particular
AEAD algorithm with additional functionality as a conventional AEAD
algorithm ...
-->
14) <!-- [rfced] Abbreviations
a) FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Encapsulating Security Payload (ESP)
Secure Real-time Transport Protocol (SRTP)
Voice over IP (VoIP)
Multilinear Galois Mode (MGM)
Synthetic Initialization Vector (SIV)
Galois/Counter Mode (GCM)
b) How should "CCA" be expanded here? As "Congestion Control Algorithm (CCA)"
or something else? Also, how should "CPA" be expanded here? As "Certification
Path Advertisement (CPA)"?
Original:
Security notion: CPA resilience (confidentiality), authenticity
resilience (integrity), CCA resilience (authenticated encryption)
[ADL17].
c) How should "RAE" be expanded? As "Robust Authenticated Encryption" or
something else?
Original:
Security notion: RAE [HKR2015].
c) Should any of the following be expanded or defined? Are these names of
things rather than abbreviations that should be expanded?
Note that these do not appear on our Abbreviations List at
https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list. Also note that we
do not expand fixed names for things (e.g., algorithms like AES-GCM).
IND-CPA
IND-CTXT
D-LORS-BCPA
B-INT-CTXT
INT-RUP
GCM-RUP
SAEF
CMT
CMT-4
CMT-1
CIL1
CCAL1
CCAmL2
TEDT
MRAE
QCB
AEZ
mu-ind
-->
15) <!-- [rfced] Lists in Sections 4 and Appendix A
a) May we update "Security notion:" to "Security notions:" (plural)
throughout? We see that "Examples:" and "Applications:" are plural.
b) We used newline="true" for these lists; let us know if you would like to
use newline="false" instead.
Example of newline="true":
Definition:
An AEAD algorithm guarantees that the plaintext is not available
to an active, nonce-respecting adversary.
Security notion:
IND-CCA [BN2000] (or IND-CCA2 [S04])
Synonyms:
Message privacy
Example of newline="false":
Definition: An AEAD algorithm allows one to ensure that the
ciphertext and the associated data have not been changed or forged
by an active, nonce-respecting adversary.
Security notion: IND-CTXT [BN2000] (or AUTH [R02])
Synonyms: Message authentication, authenticity
-->
16) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
Thank you.
RFC Editor/rv
On Apr 17, 2025, at 3:55 PM, rfc-edi...@rfc-editor.org wrote:
*****IMPORTANT*****
Updated 2025/04/17
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* rfc-edi...@rfc-editor.org (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* auth48archive@rfc-editor.org, which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
auth48archive@rfc-editor.org will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9771.xml
https://www.rfc-editor.org/authors/rfc9771.html
https://www.rfc-editor.org/authors/rfc9771.pdf
https://www.rfc-editor.org/authors/rfc9771.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9771-diff.html
https://www.rfc-editor.org/authors/rfc9771-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9771-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9771
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9771 (draft-irtf-cfrg-aead-properties-09)
Title : Properties of AEAD Algorithms
Author(s) : A. Bozhko
WG Chair(s) :
Area Director(s) :
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
