and to really nail this down, NIST also agrees to AES-CCM. Huzzah! Deb
On Fri, Sep 26, 2025 at 11:50 AM Deb Cooley <[email protected]> wrote: > 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]
