Hi Andrey, This is a friendly reminder that this document awaits your attention. Please review the document-specific questions and AUTH48 announcement below. Let us know if we can be of assistance as you begin the AUTH48 review process.
AUTH48 status page of this document: https://www.rfc-editor.org/auth48/rfc9771 AUTH48 FAQs: https://www.rfc-editor.org/faq/#auth48 We look forward to hearing from you at your earliest convenience. Best regards, RFC Editor/rv > On Apr 17, 2025, at 3:59 PM, rfc-edi...@rfc-editor.org wrote: > > 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
