Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
1) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on <https://www.rfc-editor.org/search>. --> 2) <!-- [rfced] Abstract: We do not see "Group Key Agreement protocol" in the text of any published RFC. Should this term be lowercased or perhaps explained in the body of the document? Original: The Messaging Layer Security (MLS) protocol (I-D.ietf-mls-protocol) provides a Group Key Agreement protocol for messaging applications. --> 3) <!-- [rfced] Sections 2.2 and subsequent: After the initial definition of "AS" in Section 2.2, we see alternating use of "AS" and "Authentication Service". Would you like to use the abbreviation in running text after the initial definition? We have the same question for * "DS" and "Delivery Service" * "FS" and "Forward Secrecy" * "PCS" and "Post-Compromise Security" It seems that each of these terms is used often enough that the abbreviations could be used after the terms are first defined. A few examples (for "DS" and "AS"; "Delivery Services, which is responsible ..." has been corrected): * A Delivery Service (DS) which can receive and distribute messages between group members. In the case of group messaging, the delivery service may also be responsible for acting as a "broadcaster" where the sender sends a single message which is then forwarded to each recipient in the group by the DS. ... It is important to note that the Authentication Service can be completely abstract in the case of a Service Provider which allows MLS clients to generate, distribute, and validate credentials themselves. As with the AS, the Delivery Service can be completely abstract if users are able to distribute credentials and messages without relying on a central Delivery Service (as in a peer-to-peer system). Note, though, that in such scenarios, clients will need to implement logic that assures the delivery properties required of the DS (see Section 5.2). ... She sends both of these messages to the Delivery Services, which is responsible for sending them to the appropriate people. Note that the security of MLS does not depend on the DS forwarding the Welcome message only to Bob, as it is encrypted for him; it is simply not necessary for other group members to receive it. ... The Authentication Service design is left to the infrastructure designers. In most designs, a compromised AS is a serious matter, as the AS can serve incorrect or attacker-provided identities to clients. --> 4) <!-- [rfced] Sections 2.2 and subsequent: We found the use of "which" in this document confusing at times. Please review and let us know how we may update the document. We found the following confusing: * An Authentication Service (AS) which is responsible for attesting to bindings between application-meaningful identifiers and the public key material used for authentication in the MLS protocol. The AS must also be able to generate credentials that encode these bindings and validate credentials provided by MLS clients. * A Delivery Service (DS) which can receive and distribute messages between group members. In the case of group messaging, the delivery service may also be responsible for acting as a "broadcaster" where the sender sends a single message which is then forwarded to each recipient in the group by the DS. The DS is also responsible for storing and delivering initial public key material required by MLS clients in order to proceed with the group secret key establishment that is part of the MLS protocol. ... Alice, Bob, and Charlie authenticate to the DS and store some initial keying material which can be used to send encrypted messages to them for the first time. ... The simplest pattern is for a client to just send a Commit which contains one or more Proposals, for instance Alice could send a Commit with the Proposal Add(Bob) embedded to add Bob to the group. ... In the centralized setting, DoS protection can typically be performed by using tickets or cookies which identify users to a service for a certain number of connections. ... Each encrypted MLS message carries a "generation" number which is a per-sender incrementing counter. ... In this section, we consider the case where the signature keys are not compromised, which can occur if the attacker has access to part of the memory containing the group secrets but not to the signature keys which might be stored in a secure enclave. ... This in turn induces a signature key rotation which could provide the attacker with part or the full value of the private key depending on the architecture of the service provider. --> 5) <!-- [rfced] Section 3.4: "or to key other protocols" reads oddly. Are some words missing, or does the text indicate that other protocols are keyed? In other words, is "key" used as a verb here? Original: At the completion of this process, we have a group with Alice, Bob, and Charlie, which means that they share a single encryption key which can be used to send messages or to key other protocols. --> 6) <!-- [rfced] Section 4: Should "the security considerations" be "Section 8" or some other section? Original: Some security trade-offs related to this flexibility are discussed in the security considerations. --> 7) <!-- [rfced] Section 5.1: The only published RFC to date that mentions "init_key" is Normative Reference RFC 9420. May we cite it here for ease of the reader? This question also applies to "epoch_authenticator" and any other parameters mentioned in this document and defined in RFC 9420. Alternatively, we could add this sentence to the end of the Introduction section: It is expected that readers are familiar with the terms used in [RFC9420]. Original: When a client wishes to establish a group or add clients to a group, it first contacts the Delivery Service to request KeyPackages for each other client, authenticates the KeyPackages using the signature keys, includes the KeyPackages in Add Proposals, encrypts the information needed to join the group (the _GroupInfo_ object) with an ephemeral key, then separately encrypts the ephemeral key with the init_key from each KeyPackage. Suggested: When a client wishes to establish a group or add clients to a group, it first contacts the Delivery Service to request KeyPackages for each other client, authenticates the KeyPackages using the signature keys, includes the KeyPackages in Add Proposals, and encrypts the information needed to join the group (the _GroupInfo_ object) with an ephemeral key; it then separately encrypts the ephemeral key with the init_key [RFC9420] from each KeyPackage. --> 8) <!-- [rfced] Sections 5.1 and subsequent: Do you think other documents may want to refer to specific recommendations in this document? We wonder whether it would be helpful to number the recommendations (e.g., Recommendation 1, or Req 1). In addition, as <strong> is used for RECOMMENDATION, may we change this to Recommendation? The use of capitalization seems unnecessary since it's already bold. --> 9) <!-- [rfced] Sections 5.2.1 and 8.1.4: As it appears that "ones" in these sentences refers to Commits, we changed "ones" to "Commits". If this is incorrect, please clarify the text. Original: This would allow clients to only apply the first valid Commit for an epoch and ignore subsequent ones. ... As discussed in Section 5, the Delivery Service is trusted to select the single Commit message that is applied in each epoch from among the ones sent by group members. Currently: This would allow clients to only apply the first valid Commit for an epoch and ignore subsequent Commits. ... As discussed in Section 5, the Delivery Service is trusted to select the single Commit message that is applied in each epoch from among the Commits sent by group members. --> 10) <!-- [rfced] Section 5.2.2: Does "offers" refer to the Delivery Service or the way? Original: With this approach, the Delivery Service is built in a way that may be significantly more available or performant than a strongly consistent system, but offers weaker consistency guarantees. Perhaps (the Delivery Service): With this approach, the Delivery Service is built in a way that may be significantly more available or performant than a strongly consistent system, but it offers weaker consistency guarantees. Or possibly (the way): With this approach, the Delivery Service is built in a way that may be significantly more available or performant than a strongly consistent system but that offers weaker consistency guarantees. --> 11) <!-- [rfced] Section 5.3: This sentence does not parse. If neither suggestion below is correct, please clarify. Original: The DS can enable clients to choose between Commits, for example by providing Commits in the order received and allow clients to reject any Commits that violate their view of the group's policies. Suggestion #1: The DS can enable clients to choose between Commits - for example, by providing Commits in the order received and allowing clients to reject any Commits that violate their view of the group's policies. Suggestion #2: The DS can enable clients to choose between Commits - for example, by providing Commits in the order received - and allow clients to reject any Commits that violate their view of the group's policies. --> 12) <!-- [rfced] Section 6.1: The comma in this sentence makes it difficult to parse. Is the comma necessary? Original: Some applications may wish to enforce ACLs to limit addition or removal of group members, to privileged clients or users. --> 13) <!-- [rfced] Section 6.1: Because "primary" is used instead of "first", should "second" in the next sentence be "secondary"? Original: The primary mechanism is for an authorized member of the group to send a Commit that adds or removes other members. The second mechanism is an "external join": A member of the group publishes certain information about the group, which a new member can use to construct an "external" Commit message that adds the new member to the group. --> 14) <!-- [rfced] Section 6.2: Does "they have" refer to "a user" (in which case "they have" should be "the user has") or something else? Original: Applications can strengthen connectivity among parallel groups by requiring periodic key updates from a user across all groups in which they have membership. --> 15) <!-- [rfced] Section 6.4: a) We see "add and remove operations" here but "Remove Proposal" in Section 3.6 and "Remove group operation" in Section 8.3.1.3. Should "add and remove operations" be changed to "Add and Remove operations"? Original: On the one hand, an application could decide that a group administrator will be the only member to perform add and remove operations. b) Regarding "Remove Proposal" and "Add Proposal" as used in this document: RFC 9420 uses "Remove proposal" and "Add proposal" in its text. Would you like to use lowercase "proposal" in this document per RFC 9420? --> 16) <!-- [rfced] Section 6.4: It is not clear what "for example" refers to in this sentence. If the suggested text is not correct, please clarify. Original: Applications may be designed such that intermediaries need to see handshake messages, for example to enforce policy on which commits are allowed, or to provide MLS ratchet tree data in a central location. Suggested (removing the comma after "allowed"): Applications may be designed such that intermediaries need to see handshake messages - for example, to enforce policy on which commits are allowed or to provide MLS ratchet tree data in a central location. --> 17) <!-- [rfced] Section 6.9: We do not see the word "default" or any indication of a default mechanism in Section 3.3 of [I-D.ietf-mls-extensions]. Please confirm that the text and citation are correct and will be clear to readers. Original: *RECOMMENDATION:* Use the default content mechanism defined in Section 3.3 of [I-D.ietf-mls-extensions], unless the specific application defines another mechanism which more appropriately addresses the same requirements for that application of MLS. --> 18) <!-- [rfced] Section 7: This sentence is difficult to parse. To what does ", or for two deployments to potentially interoperate" refer? If the suggested text is not correct, please clarify. Original: This section lists all of the dependencies of an MLS deployment that are external to the protocol specification, but would still need to be aligned within a given MLS deployment, or for two deployments to potentially interoperate. Suggested: This section lists all of the dependencies of an MLS deployment that are external to the protocol specification but would still need to be aligned within a given MLS deployment so that two deployments can potentially interoperate. --> 19) <!-- [rfced] Section 7: As it appears that "they have" refers to "one device", we changed "they have" to "the device has". If this is incorrect, please clarify the text. Original: However, one device may control multiple signature keys - for instance if they have keys corresponding to multiple overlapping time periods - but should still only be considered a single client. Currently: However, one device may control multiple signature keys - for instance, if the device has keys corresponding to multiple overlapping time periods - but should still only be considered a single client. --> 20) <!-- [rfced] Section 8.1.4: Is tampering by the Delivery Service the only type of tampering scenario (in which case "i.e.," is correct), or is it one example of a tampering scenario (in which case "e.g.," would be correct)? Original: As noted above, MLS is designed to provide some robustness in the face of tampering within the secure transport, i.e., tampering by the Delivery Service. --> 21) <!-- [rfced] Section 8.2.2: Does "Forward" here refer to Forward Secrecy (FS) or forward security as mentioned in Section 8.4.2? Please note that we only see one instance of "forward security" in this document (Section 8.4.2) and do not see this term used in RFC 9420. Original: 8.2.2. Forward and Post-Compromise Security --> 22) <!-- [rfced] Section 8.2.2: We had trouble following this sentence. Does "by active members including freshness" mean "by active members ensuring freshness of data" or something else? Original: MLS partially defends against this problem by active members including freshness, however not much can be done on the inactive side especially in the case where the client has not processed messages. --> 23) <!-- [rfced] Section 8.2.2: "followed" read oddly in this sentence. We updated the text. If this is incorrect, please clarify the meaning of "followed". Original: These recommendations will reduce the ability of idle compromised clients to decrypt a potentially long set of messages that might have followed the point of the compromise. Currently: These recommendations will reduce the ability of idle compromised clients to decrypt a potentially long set of messages that might have been sent after the point of compromise. --> 24) <!-- [rfced] Section 8.2.4: Should "the clients' state remain" be "the clients' state remains" or "the clients' states remain"? Original: However, the application would need to provide a synchronization mechanism so that the clients' state remain consistent across changes to the MLS group. --> 25) <!-- [rfced] Section 8.3.1: "a per-sender with" in this sentence is difficult to follow. If the suggested text is not correct, please clarify. Original: These group secrets are then used to create a per-sender Ratchet Secret, which in turn is used to create a per-sender with additional data (AEAD) [RFC5116] key that is then used to encrypt MLS Plaintext messages. Suggested: These group secrets are then used to create a per-sender Ratchet Secret, which in turn is used to create a per-sender key with additional data (Authenticated Encryption with Associated Data (AEAD); see [RFC5116]) that is then used to encrypt MLS Plaintext messages. --> 26) <!-- [rfced] Section 8.3.1.1: For ease of the reader, we expanded "HPKE" as "Hybrid Public Key Encryption". If this is incorrect, please provide the correct definition. Original: In the case of a Group Operation message, only the privacy is affected, as the signature is revealed, because the secrets themselves are protected by HPKE encryption. Currently: In the case of a Group Operation message, only the privacy is affected, as the signature is revealed, because the secrets themselves are protected by Hybrid Public Key Encryption (HPKE). --> 27) <!-- [rfced] Section 8.3.1.1: This sentence as written appeared to say that the compromise cannot forge the signature. We updated it to indicate that the attacker cannot forge the signature. If this is incorrect, please provide clarifying text. Original: Compromise of the AEAD keys allows the attacker to send an encrypted message using that key, but cannot send a message to a group which appears to be from any valid client since they cannot forge the signature. Currently: Compromise of the AEAD keys allows the attacker to send an encrypted message using that key, but the attacker cannot send a message to a group that appears to be from any valid client because the attacker cannot forge the signature. --> 28) <!-- [rfced] Section 8.3.1.2: Does "both the current AEAD keys for a given sender as well as any future keys" mean "both of the current AEAD keys for a given sender, as well as any future keys", "both (1) the current AEAD keys for a given sender and (2) any future keys", or something else? Original: When a Ratchet Secret is compromised, the adversary can compute both the current AEAD keys for a given sender as well as any future keys for that sender in this epoch. --> 29) <!-- [rfced] Section 8.3.3: Given "dedicated hardware features" in this sentence, we expanded "HSM" as "Hardware Security Module" for ease of the reader. If this is incorrect, please provide the correct definition. Original: *RECOMMENDATION:* Signature private keys should be compartmentalized from other secrets and preferably protected by an HSM or dedicated hardware features to allow recovery of the authentication for future messages after a compromise. Currently: *RECOMMENDATION:* Signature private keys should be compartmentalized from other secrets and preferably protected by a Hardware Security Module (HSM) or dedicated hardware features to allow recovery of the authentication for future messages after a compromise. --> 30) <!-- [rfced] Section 8.4.1.1: For ease of the reader, we expanded "MASQUE" and "ToR". If the definition of "ToR" is incorrect, please provide the correct definition. (The definition of "MASQUE" was taken from draft-schinazi-masque-proxy.) Original: *RECOMMENDATION:* In the case where privacy or anonymity is important, using adequate protection such as MASQUE [I-D.schinazi-masque-proxy], ToR, or a VPN can improve metadata protection. Currently: *RECOMMENDATION:* In the case where privacy or anonymity is important, using adequate protection such as Multiplexed Application Substrate over QUIC Encryption (MASQUE) [MASQUE-PROXY], Top-of-Rack (ToR) switches, or a VPN can improve metadata protection. --> 31) <!-- [rfced] Section 8.4.2.1: We had trouble parsing this sentence. Are some words missing? If the suggested text is not correct, please clarify "they" and "content, which is typically encrypted MLS messages". Original: Even though they can't necessarily access the content, which is typically encrypted MLS messages, the service provider and the push notification provider have to be trusted to avoid making correlation on which devices are recipients of the same message. Suggested: Even though the service provider and the push notification provider can't necessarily access the content (typically encrypted MLS messages), they have to be trusted to avoid making correlations regarding which devices are recipients of the same message. --> 32) <!-- [rfced] Section 8.4.3.1: In this document's XML file, all other parameters containing underscores are placed in <tt>s except for "authentication_secret". May we place it in <tt>s and remove the quotes? Original: The "authentication_secret" generated for each user at each epoch of the group is a one-time, per client, authentication secret which can be exchanged between users to prove their identity to each other. --> 33) <!-- [rfced] Section 8.4.3.2: It is not clear to us whether "they" in the second sentence refers to "all clients" or "the server" in the first sentence. Please clarify. Original (the run-on sentence has been fixed): In the case of client fanout, the destination of a message is known by all clients, hence the server usually does not need this information. However, they may learn this information through traffic analysis. --> 34) <!-- [rfced] [BCK21]: We updated this listing to use the title found on the provided URL, as we found "Cryptographic Security of the MLS RFC, Draft 11" on <https://eprint.iacr.org/2021/137> but again found "Security Analysis of the MLS Key Distribution" when we clicked "PDF" under "Available format(s)". Please let us know any concerns. Original: [BCK21] Brzuska, C., Cornelissen, E., and K. Kohbrok, "Cryptographic Security of the MLS RFC, Draft 11", 2021, <https://eprint.iacr.org/2021/137.pdf>. Currently: [BCK21] Brzuska, C., Cornelissen, E., and K. Kohbrok, "Security Analysis of the MLS Key Distribution", Cryptology ePrint Archive, 2021, <https://eprint.iacr.org/2021/137.pdf>. --> 35) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide at <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. --> 36) <!-- [rfced] Please let us know if any changes are needed for the following: a) The following term was used inconsistently in this document. We chose to use the latter form. Please let us know any objections. last resort (2 instances) / "last resort" (4 instances) (per Normative Reference RFC 9420) b) The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. Would you like us to follow usage in Normative Reference RFC 9420 ("The Messaging Layer Security (MLS) Protocol")? Most of the terms listed below are also used in RFC 9420. We have marked them with asterisks ("*"). * Application message (3 instances) / application message (12 instances) (e.g., "an Application message", "an application message") (RFC 9420 uses "application message".) * authentication service (Abstract) / Authentication Service (16 instances) (RFC 9420 uses "Authentication Service".) * commit (>=13 instances) / Commit (>50 instances) (e.g., "the commit", "the Commit", "any commits", "any Commits") (RFC 9420 uses both forms but appears to use lowercase when this term is used generally. Please review usage in this document and advise.) * credential type (1 instance) / Credential type (8 instances) (We also see "credential types" in Section 7.) (RFC 9420 uses "credential type".) * delivery service (2 instances) / Delivery Service (>40 instances) (RFC 9420 uses "Delivery Service".) Eventually Consistent / eventually consistent (1 instance each) (We also see "strongly and eventually consistent systems" in Section 5.2.) * forward secrecy (3 instances) / Forward Secrecy (1 instance other than where defined) (RFC 9420 uses "forward secrecy". We changed "forward-secrecy" in this document to "forward secrecy" for now.) * group / Group (used generally) (e.g., "a group", "a Group", "the group", "that group", "that Group") (RFC 9420 uses "a group", "the group", "that group", etc.) group operation message (7 instances) / Group Operation message (2 instances in Section 8.3.1.1) * group secret (10 instances) / Group Secret (2 instances) / Group secret (1 instance) (RFC 9420 uses "group secret".) * Handshake message (2 instances) / handshake message (9 instances) (RFC 9420 uses "handshake message".) Key Transparency (2 instances) / key transparency (2 instances) (e.g., "Key Transparency [KT]", "key transparency mechanism") * keypair (4 instances) / key pair (5 instances) (RFC 9420 uses "key pair".) * Member (3 instances) / member (>50 instances) (used generally) (e.g., "When a client is part of a Group, it is called a Member", "all Members", "all members") (RFC 9420 uses "member".) * Plaintext (1 instance) / plaintext (3 instances) ("MLS Plaintext messages", "plaintext and ciphertext messages") (RFC 9420 uses "plaintext" in running text.) * post-compromise security / Post-Compromise Security (RFC 9420 uses "post-compromise security".) * proposal (23 instances) / Proposal (5 instances) (used generally, e.g., "the proposal", "the Proposal", "of proposals", "of Proposals") RFC 9420 uses initial capitalization when referring to a Proposal object and lowercase when used generally. We cannot determine general uses versus referring to a Proposal object here. Please review and advise. push notification (adj.) (5 instances) / push-notification (adj.) (1 instance) (e.g., "push notification provider", "push notification infrastructure", "push-notification system") (Usage in post-6000 published RFCs is mixed.) push tokens (1 instance) / push-tokens (3 instances) (No precedent in published RFCs.) * ratchet secret (1 instance) / Ratchet Secret (11 instances) (RFC 9420 uses "ratchet secret".) ReInit proposal (3 instances in Section 5.2.3) / reinitialization proposal (2 instances in Section 7) Service Provider (2 instances) / service provider (10 instances) Strongly Consistent (2 instances) / strongly consistent (1 instance) * x509 / X.509 ("x509 Credential type", "X.509 certificates") (RFC 9420 uses "X509Credential" and "X.509 credential".) c) In the XML file, we see that emphasis ("<em>") for "Welcome message" is applied three times, while all other instances of "<em>" are used only once for a given word or term (where the term is first used). Is "Welcome message" a special case, or should the second and third instances of "<em>" be removed for this term? d) Would you like spacing to be consistent? Welcome (Bob) / Add(Bob) (RFC 9420 does not use spacing between "Welcome" or "Add" and the parenthetical item that follows those terms.) Notes re. the SVG: In the SVG for Figure 2, we found that a closing parenthesis was missing after the first "Bob": <text x="84" y="292">(Bob</text> We added the closing parenthesis. However, as a result, there isn't a space between "(Bob)" and the arrow line. If you want to change "Welcome (Bob)" to "Welcome(Bob)" in line with RFC 9420, we will need you to modify the entries in the SVG. If you want to have a space after the first "Bob" in Figure 2, we will need you to make that update as well. --> Thank you. RFC Editor On Feb 24, 2025, at 3:16 PM, rfc-edi...@rfc-editor.org wrote: *****IMPORTANT***** Updated 2025/02/24 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/rfc9750.xml https://www.rfc-editor.org/authors/rfc9750.html https://www.rfc-editor.org/authors/rfc9750.pdf https://www.rfc-editor.org/authors/rfc9750.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9750-diff.html https://www.rfc-editor.org/authors/rfc9750-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9750-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9750 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC 9750 (draft-ietf-mls-architecture-15) Title : The Messaging Layer Security (MLS) Architecture Author(s) : B. Beurdouche, E. Rescorla, E. Omara, S. Inguva, A. Duric WG Chair(s) : Nick Sullivan, Sean Turner Area Director(s) : Deb Cooley, Paul Wouters -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
