I checked with the author of RFC 4309 who prefers the hyphen. So AES-CCM, please.
Deb On Fri, Sep 26, 2025 at 10:24 AM Deb Cooley <[email protected]> wrote: > I'm going to make some inquiries (to authors and NIST), like Valery, this > looks very strange. If one or the other is correct, I'm going to pick > that... > > Stay tuned. > > Deb > > On Fri, Sep 26, 2025 at 9:48 AM Madison Church < > [email protected]> wrote: > >> Hi Valery and Brian, *Debbie, >> >> Thank you both for your replies and patience as we incorporate your >> requested changes! We have updated the document and have a few followup >> questions/comments inline (for easy readability, we have only included >> outstanding questions in this thread). >> >> *Debbie - As responsible AD for this document, please see question 14 and >> let us know if you approve the change made to the first sentence in Section >> 2.5. The change may be viewed in this diff file: >> https://www.rfc-editor.org/authors/rfc9838-diff.html. >> >> >>> 4) <!-- [rfced] Please review whether any of the notes in this >> document >> >>> should be in the <aside> element. It is defined as "a container for >> >>> content that is semantically less important or tangential to the >> >>> content that surrounds it" ( >> https://authors.ietf.org/en/rfcxml-vocabulary#aside). >> >>> --> >> >> >> >> I'm not sure I understand the visual effect of <aside> element (I >> guess this is an xml2rfc v3 feature). >> >> Can you point me to RFCs that use this element? >> >> >> >> And do you have some parts of this document in mind that >> >> this element can be useful for? >> >> 1) Depending on author preference, we will occasionally use <aside> for >> text marked as "Note:". The output yields a visual of indented text with a >> vertical line on the left. For example, RFCs 9800 [1] and 9801 [2] utilize >> the <aside> element frequently. >> >> As for areas in this document that may benefit from the <aside>, the last >> sentence of Section 1 (Introduction and Overview) contains a note. >> >> [1]: https://www.rfc-editor.org/rfc/rfc9800.txt >> [2]: https://www.rfc-editor.org/rfc/rfc9801.txt >> >> >>> 14) <!-- [rfced] We have updated this sentence to use "AES CCM" (per >> >>> RFC 4309) rather than "AES-CCM". Please let us know any >> >>> objections. >> >>> >> >>> Original: >> >>> Several counter-based modes of operation have been specified for ESP >> >>> (e.g., AES-CTR [RFC3686], AES-GCM [RFC4106], AES-CCM [RFC4309], >> >>> ChaCha20-Poly1305 [RFC7634], AES-GMAC [RFC4543]) and AH (e.g., AES- >> >>> GMAC [RFC4543]). >> >>> >> >>> Current: >> >>> Several counter-based modes of operation have been specified for ESP >> >>> (e.g., AES-CTR [RFC3686], AES-GCM [RFC4106], AES CCM [RFC4309], >> >>> ChaCha20-Poly1305 [RFC7634], and AES-GMAC [RFC4543]) and AH (e.g., >> AES- >> >>> GMAC [RFC4543]). >> >>> --> >> >> >> >> Hmm, obviously, I should have no objections to this as RFC 4309 uses >> this form >> >> but actually this is a big surprise for me: the lack of consistency in >> naming :-) >> >> >> >> And a number of RFCs related to IPsec (I suspect there are others too) >> actually use "AES-CCM" form >> >> (RFC8247, RFC7321). Thus, I have no position and rely on AD's decision >> on this. >> >> >> >>> 22) <!-- [rfced] May we restructure the text below as follows for >> readability? >> >>> >> >>> Current: >> >>> This transform ID defines the following properties. Sequence >> numbers >> >>> are 32-bit in size and are transmitted in the Sequence Number field >> of AH and >> >>> ESP packets. The value of sequence numbers is not guaranteed to be >> unique for >> >>> the duration of an SA, thus they are not suitable for replay >> protection. This >> >>> transform ID MUST be used by the GCKS in case of multi-sender >> multicast >> >>> Data-Security SAs utilizing protocols ESP or AH to inform the GMs >> that the >> >>> replay protection is not expected to be possible. The GCKS MAY >> also use this >> >>> transform ID for single-sender multicast Data-Security SAs if replay >> >>> protection is not needed (e.g. it is done on application level). >> >>> >> >>> >> >>> Perhaps: >> >>> This transform ID defines the following properties: >> >>> >> >>> * Sequence numbers are 32 bits in size and are transmitted in the >> Sequence >> >>> Number field of AH and ESP packets. >> >>> >> >>> * The value of sequence numbers is not guaranteed to be unique for >> >>> the duration of an SA, thus they are not suitable for replay >> >>> protection. >> >>> >> >>> * This transform ID MUST be used by the GCKS in the case of >> multi-sender >> >>> multicast Data-Security SAs utilizing protocols ESP or AH to >> inform >> >>> the GMs that the replay protection is not expected to be possible. >> >>> >> >>> * The GCKS MAY also use this transform ID for single-sender >> multicast >> >>> Data-Security SAs if replay protection is not needed (e.g., it is >> done >> >>> on the application level). >> >>> --> >> >> >> >> Actually, only two first bullet define the properties, the last two >> >> just explain how to use this transform ID. I propose instead the >> following >> >> variants. >> >> >> >> Option A - split para and do not add list: >> >> >> >> NEW (Option A): >> >> This transform ID defines the >> >> following properties. Sequence numbers are 32 bits in size and are >> >> transmitted in the Sequence Number field of AH and ESP packets. The >> >> value of sequence numbers is not guaranteed to be unique for the >> >> duration of an SA, thus they are not suitable for replay protection. >> >> >> >> This transform ID MUST be used by the GCKS in case of multi-sender >> >> multicast Data-Security SAs utilizing protocols ESP or AH to inform >> >> the GMs that the replay protection is not expected to be possible. >> >> The GCKS MAY also use this transform ID for single-sender multicast >> >> Data-Security SAs if replay protection is not needed (e.g., it is >> >> done on the application level). >> >> >> >> Option B - use list for properties only: >> >> >> >> NEW (Option B): >> >> This transform ID defines the following properties: >> >> >> >> * Sequence numbers are 32 bits in size and are transmitted in the >> Sequence >> >> Number field of AH and ESP packets. >> >> >> >> * The value of sequence numbers is not guaranteed to be unique for >> >> the duration of an SA, thus they are not suitable for replay >> >> protection. >> >> >> >> This transform ID MUST be used by the GCKS in case of multi-sender >> >> multicast Data-Security SAs utilizing protocols ESP or AH to inform >> >> the GMs that the replay protection is not expected to be possible. >> >> The GCKS MAY also use this transform ID for single-sender multicast >> >> Data-Security SAs if replay protection is not needed (e.g., it is >> >> done on the application level). >> >> >> >> I have no preferences, but perhaps option B looks a bit neater. >> > >> > I’m fine with either of Valery’s proposals but also prefer Option B. >> >> 2) Thank you for your proposal! We have updated the document to use >> Option B. >> >> >>> 39) <!-- [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. >> >>> >> >>> For example, please consider whether the term "man-in-the-middle" >> should be >> >>> updated. --> >> >> >> >> I believe we can use "person-in-the-middle" instead. >> >> I failed to find other issues with inclusive language guide in the >> text. >> > >> > Alternatively, “On-Path Attack Protection”. >> >> 3) We have updated to use "on-path attack protection" (as this is a >> common replacement for "man-in-the-middle"). >> >> >> 40) Not all new IANA registries added to >> https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml >> >> are properly filled in. In particular, the "Reserved for Private Use" >> ranges in the "GSA Attributes", >> >> the "Group-wide Policy Attributes" and the "Member Key Bag Attributes" >> registries do not >> >> reference to this document (while the "Group Key Bag Attributes" >> registry does). >> >> 4) Thank you for pointing this out! We will ask IANA to update these >> registries. We will also ask them to correct the "Unassigned" range in >> Table 13 (as mentioned in mail from 9/24). >> >> >> I also have a proposal. The draft references >> draft-ietf-ipsecme-ikev2-qr-alt-10, >> >> which is currently in the RFC Editor queue in the state "AUTH48". >> >> While it is only informatively referenced, I think that it would be >> better if it is referenced >> >> as RFC and not as I-D. Can you please make this possible (I think it >> would require adding >> >> draft-ietf-ipsecme-ikev2-qr-alt-10 to C532 cluster). >> >> 5) Understood! As of right now, the document is cited as >> [IPSEC-IKEV2-QR-ALT] in the text. Would you like to update to use [RFC9867]? >> >> The files have been posted here (please refresh): >> https://www.rfc-editor.org/authors/rfc9838.txt >> https://www.rfc-editor.org/authors/rfc9838.pdf >> https://www.rfc-editor.org/authors/rfc9838.html >> https://www.rfc-editor.org/authors/rfc9838.xml >> >> Diff files: >> https://www.rfc-editor.org/authors/rfc9838-diff.html >> https://www.rfc-editor.org/authors/rfc9838-rfcdiff.html (side by side) >> https://www.rfc-editor.org/authors/rfc9838-auth48diff.html >> https://www.rfc-editor.org/authors/rfc9838-auth48rfcdiff.html (side >> by side) >> >> For the AUTH48 status page, please see: >> https://www.rfc-editor.org/auth48/rfc9838. >> >> Thank you! >> >> Madison Church >> RFC Editor >> >> >> Regards, >> >> Valery. >> >> >> >> >> >>> Thank you. >> >>> >> >>> Madison Church and Karen Moore >> >>> RFC Production Center >> >>> >> >>> >> >>> On Sep 11, 2025, at 7:14 PM, RFC Editor via auth48archive < >> [email protected]> wrote: >> >>> >> >>> *****IMPORTANT***** >> >>> >> >>> Updated 2025/09/11 >> >>> >> >>> 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/rfc9838.xml >> >>> https://www.rfc-editor.org/authors/rfc9838.html >> >>> https://www.rfc-editor.org/authors/rfc9838.pdf >> >>> https://www.rfc-editor.org/authors/rfc9838.txt >> >>> >> >>> Diff file of the text: >> >>> https://www.rfc-editor.org/authors/rfc9838-diff.html >> >>> https://www.rfc-editor.org/authors/rfc9838-rfcdiff.html (side by >> side) >> >>> >> >>> Diff of the XML: >> >>> https://www.rfc-editor.org/authors/rfc9838-xmldiff1.html >> >>> >> >>> >> >>> Tracking progress >> >>> ----------------- >> >>> >> >>> The details of the AUTH48 status of your document are here: >> >>> https://www.rfc-editor.org/auth48/rfc9838 >> >>> >> >>> Please let us know if you have any questions. >> >>> >> >>> Thank you for your cooperation, >> >>> >> >>> RFC Editor >> >>> >> >>> -------------------------------------- >> >>> RFC9838 (draft-ietf-ipsecme-g-ikev2-23) >> >>> >> >>> Title : Group Key Management using IKEv2 >> >>> Author(s) : V. Smyslov, B. Weis >> >>> WG Chair(s) : Yoav Nir, Tero Kivinen >> >>> >> >>> Area Director(s) : Deb Cooley, Paul Wouters >> >>> >> >>> >> >>> -- >> >>> auth48archive mailing list -- [email protected] >> >>> To unsubscribe send an email to [email protected] >> >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
