Hi Rebecca, all, I've reviewed the current version and approve the document as it stands. Thank you very much!
Best regards, Andrey On Thu, May 1, 2025 at 6:59 PM Rebecca VanRheenen < [email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]> 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 < > [email protected]> 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, [email protected] 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, [email protected] 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 > >>>> > >>>> * [email protected] (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). > >>>> > >>>> * [email protected], 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, > >>>> [email protected] 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 -- [email protected] To unsubscribe send an email to [email protected]
