Hi Alexey, We have marked your approval on the AUTH48 status page for this document (see https://www.rfc-editor.org/auth48/rfc9771).
Once we receive approval from Andrey, we will move this document forward in the publication process. Thank you, RFC Editor/rv > On May 1, 2025, at 7:35 AM, Alexey Melnikov <alexey.melni...@isode.com> wrote: > > Hi Rebecca, > > On 30/04/2025 06:11, Rebecca VanRheenen wrote: >> Hi Andrey, >> >> Thank you for addressing all of our questions and updating the xml file! >> Note that we also added expansions for RAE, CCA, and CPA in the xml file. >> >> Please review the document carefully to ensure satisfaction as we do not >> make changes once it has been published as an RFC. Let us know if you have >> any further updates or if you approve the document in its current form. >> >> *Alexey, as Document Shepherd, please review the following changes (all of >> which we consider either technical or “above editorial") and let us know if >> you approve. These changes are best viewed here: >> https://www.rfc-editor.org/authors/rfc9771-auth48diff.html. >> >> - Section 3: change from “MAY to “may" (author explanation: 'lowercased >> "may" since how particular AEADs should be defined is out of scope for this >> document’) > I can be convinced either way on this once. But I think the change is fine. >> - Section 4.3.7: addition of "[IIM25]” under Further reading (author >> explanation: “recent reference”) >> - Section 4.3.10: addition of "GCM [IIM25]” under Examples and addition of >> "[IIM25]” under Further reading (author explanation: “Added the example >> based on a resent result”) >> - Section 4.4.2: removal of "OCB [RFC7253]” from Examples > > Yes, happy with these. > > Best Regards, > > Alexey > >> >> >> — FILES (please refresh) — >> >> Updated XML file: >> https://www.rfc-editor.org/authors/rfc9771.xml >> >> Updated output files: >> https://www.rfc-editor.org/authors/rfc9771.txt >> https://www.rfc-editor.org/authors/rfc9771.pdf >> https://www.rfc-editor.org/authors/rfc9771.html >> >> Diff files showing all changes made during AUTH48: >> https://www.rfc-editor.org/authors/rfc9771-auth48diff.html >> https://www.rfc-editor.org/authors/rfc9771-auth48rfcdiff.html (side by >> side) >> >> Diff files showing all changes: >> https://www.rfc-editor.org/authors/rfc9771-diff.html >> https://www.rfc-editor.org/authors/rfc9771-rfcdiff.html (side by side) >> >> For the AUTH48 status of this document, please see: >> https://www.rfc-editor.org/auth48/rfc9771 >> >> Thank you, >> >> RFC Editor/rv >> >> >> >>> On Apr 28, 2025, at 6:16 AM, Andrey Bozhko <andb...@gmail.com> wrote: >>> >>> Hi Rebecca, all, >>> >>> Thanks to the editors for such a thorough review! >>> >>> I've provided my replies in the attached .xml file. Please note that I made >>> a few minor technical changes: I removed an example from Section 4.4.2 and >>> added a recent paper as further reading in Sections 4.3.7 and 4.3.9. >>> >>> Best, >>> Andrey >>> >>> P.S. Apologies for the delayed reply; it seems I lost the initial email >>> somewhere... >>> On Fri, Apr 25, 2025 at 8:16 PM Rebecca VanRheenen >>> <rvanrhee...@staff.rfc-editor.org> wrote: >>> 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) : >>>> >>>> >>> <rfc9771.xml> -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
