MLS J. Alwen Internet-Draft AWS Intended status: Informational B. Hale Expires: 30 March 2025 Naval Postgraduate School M. Mularczyk AWS X. Tian Naval Postgraduate School 26 September 2024 Flexible Hybrid PQ MLS Combiner draft-hale-mls-combiner-01 Abstract This document describes a protocol for combining a traditional MLS session with a post-quantum (PQ) MLS session to achieve flexible and efficient hybrid PQ security that amortizes the computational cost of PQ Key Encapsulation Mechanisms and Digital Signature Algorithms. Specifically, we describe how to use the exporter secret of a PQ MLS session, i.e. an MLS session using a PQ ciphersuite, to seed PQ guarantees into an MLS session using a traditional ciphersuite. By supporting on-demand traditional-only key updates (a.k.a. PARTIAL updates) or hybrid-PQ key updates (a.k.a. FULL updates), we can reduce the bandwidth and computational overhead associated with PQ operations while meeting the requirement of frequent key rotations. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 30 March 2025. Alwen, et al. Expires 30 March 2025 [Page 1] Internet-Draft HPQMLS September 2024 Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. About This Document . . . . . . . . . . . . . . . . . . . . . 3 3. Status of this Memo . . . . . . . . . . . . . . . . . . . . . 4 4. Copyright Notice . . . . . . . . . . . . . . . . . . . . . . 4 5. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. The Combiner Protocol Execution . . . . . . . . . . . . . . . 5 7.1. Commit Flow . . . . . . . . . . . . . . . . . . . . . . . 6 7.2. Adding a User . . . . . . . . . . . . . . . . . . . . . . 8 7.2.1. Welcome Message Validation . . . . . . . . . . . . . 9 7.2.2. External Joins . . . . . . . . . . . . . . . . . . . 9 7.3. Removing a Group Member . . . . . . . . . . . . . . . . . 9 7.4. Application Messages . . . . . . . . . . . . . . . . . . 9 8. Modes of Operation . . . . . . . . . . . . . . . . . . . . . 9 8.1. PQ/T Confidentiality Only . . . . . . . . . . . . . . . . 10 8.2. PQ/T Confidentiality + Authenticity . . . . . . . . . . . 10 9. Extension Requirements to MLS . . . . . . . . . . . . . . . . 11 9.1. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10.1. FULL Commit Frequency . . . . . . . . . . . . . . . . . 12 10.2. Attacks on Authentication . . . . . . . . . . . . . . . 13 10.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . 14 10.4. Transport Security . . . . . . . . . . . . . . . . . . . 14 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 12.1. Normative References (i.e. RFCs) . . . . . . . . . . . 14 12.2. Informational References . . . . . . . . . . . . . . . . 15 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 13.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Alwen, et al. Expires 30 March 2025 [Page 2] Internet-Draft HPQMLS September 2024 1. Introduction A fully capable quantum adversary has the ability to break fundamental underlying cryptographic assumptions of traditional Key Encapsulation Mechanisms (KEMs) and Digital Signature Algorithms (DSAs). This has led to the development of post-quantum (PQ) cryptographically secure KEMs and DSAs by the cryptographic research community which have been formally adopted by the National Institute of Standards and Technology (NIST), including the Module Lattice KEM (ML-KEM) and Module Lattice DSA (ML-DSA) algorithms. While these provide PQ security, ML-KEM and ML-DSA have significantly worse overhead in terms of public key size, signature size, ciphertext size, and CPU time than their traditional counterparts. Moreover, research arms on side-channel attacks, etc., have motivated uses of hybrid-PQ combiners that draw security from both the underlying PQ and underlying traditional components. A variety of hybrid security treatments have arisen across IETF working groups to bridge the gap between performance and security to encourage the adoption of PQ security in existing protocols, including the MLS protocol [RFC9420]. Within the MLS working group, there are several topic areas that make use of PQ security extensions: 1. A single MLS ciphersuite for a hybrid post-quantum/traditional KEM. The ciphersuite can act as a drop-in replacement for the KEM, focusing on hybrid confidentiality but not authenticity, and does not incur changes elsewhere in the MLS stack. As a confidentiality focus, it addresses the the harvest-now / decrypt-later threat model. However, every key epoch incurs a PQ overhead cost. 2. Hybrid PQ signature ciphersuites that address hybrid authenticity, including construction and security considerations of hybrid signatures. 3. Mechanisms that leverage hybridization as a means to not only address the security balance between PQ and traditional components and achieve resistance to harvest-now / decrypt-later attacks, but also use it as a means to improve performance of PQ use. This document addresses the third topic of these work items. 2. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at _[Todo]_. Alwen, et al. Expires 30 March 2025 [Page 3] Internet-Draft HPQMLS September 2024 Discussion of this document takes place on the MLS Working Group mailing list (mailto:mls@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/mls/. Subscribe at https://www.ietf.org/mailman/listinfo/mls/. Source for this draft and an issue tracker can be found at https://github.com/PairedMLS/draft-pairedMLS. 3. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." 4. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. 5. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119], and [RFC8174] when, and only when, they appear in all capitals, as shown here. Alwen, et al. Expires 30 March 2025 [Page 4] Internet-Draft HPQMLS September 2024 The terms MLS client, MLS member, MLS group, Leaf Node, GroupContext, KeyPackage, Signature Key, Handshake Message, Private Message, Public Message, and RequiredCapabilities have the same meanings as in the [MLS protocol] https://www.rfc-editor.org/rfc/rfc9420.html (https://www.rfc-editor.org/rfc/rfc9420.html). 6. Notation We use terms from from MLS [RFC9420] and PQ Hybrid Terminology [I- D.ietf-pquip-pqt-hybrid-terminology]. Below, we have restated relevant terms and define new ones: *Application Message:* A PrivateMessage carrying application data. *Handshake Message:* A PublicMessage or PrivateMessage carrying an MLS Proposal or Commit object, as opposed to application data. *Key Derivation Function (KDF):* A Hashed Message Authentication Code (HMAC)-based expand-and-extract key derivation function (HKDF) as described in RFC5869. *Key Encapsulation Mechanism (KEM):* A key transport protocol that allows two parties to obtain a shared secret based on the receiver's public key. *Post-Quantum (PQ) MLS Session:* An MLS session that uses a PQ-KEM construction, such as described by FIPS 203 from NIST. It may optionally also use a PQ-DSA construction, such as described by FIPS 204 from NIST. *Traditional MLS Session:* An MLS session that uses a Diffie-Hellman (DH) based KEM as described in RFC9180. *PQ/T*: A Post-Quantum and Traditional hybrid (protocol). 7. The Combiner Protocol Execution The hybrid PQ MLS (HPQMLS) combiner protocol runs two MLS sessions in parallel, synchronizing their group memberships. The two sessions are combined by exporting a secret from the PQ session and importing it as a Pre-Shared Key (PSK) into the traditional session. This combination process is mandatory for Commits of Add and Remove proposals in order to maintain synchronization between the sessions. However, it is optional for any other Commits (e.g. to allow for less computationally expensive traditional key rotations). Due to the higher computational costs and output sizes of PQ KEM (and signature) operations, it may be desirable to issue PQ combined (a.k.a. FULL) Commits less frequently than the traditional-only (a.k.a. PARTIAL) Alwen, et al. Expires 30 March 2025 [Page 5] Internet-Draft HPQMLS September 2024 Commits. Since FULL Commits introduce PQ security into the MLS key schedule, the overall key schedule remains PQ-secure even when PARTIAL Commits are used. The FULL Commit rate establishes the post- quantum Post-Compromise Security (PCS) window, while the PARTIAL Commit rate can tighten the traditional PCS window even while maintaining PQ security more generally. The combiner protocol design treats both sessions as black-box interfaces so we only highlight operations requiring synchronizations in this document. The default way to start a HPQMLS combined session is to create a PQ MLS session and then start a traditional MLS session with the exported PSK from the PQ session, as previously mentioned. Alternatively, a combined session can also be created after a traditional MLS session has already been running. This is done through creating a PQ MLS session with the same group members, sending a Welcome message containing the HPQMLSInfo struct in the GroupContext, and then making a FULL Commit as described in in the Commit Flow (Section 7.1) section. 7.1. Commit Flow Commits to proposals MAY be _PARTIAL_ or _FULL_. For a PARTIAL Commit, only the traditional session's epoch is updated following the Propose-Commit sequence from Section 12 of RFC9420. For a FULL Commit, a Commit is first applied to the PQ session and another Commit is applied to the traditional session using a PSK derived from the PQ session using the DeriveExtensionSecret and hpqmls_psk label (see Key Schedule (Section 9.1)). To ensure the correct PSK is imported into the traditional session, the sender includes information about the PSK in a PreSharedKey proposal for the traditional session's Commit list of proposals. The information about the exported PSK is captured (shown '=' in the figures below for illustration purposes) by the PreSharedKeyID struct as detailed in RFC9420 (https://www.rfc-editor.org/rfc/rfc9420.html#name-pre- shared-keys). Receivers process the PQ Commit to derive a new epoch in the PQ session and then the traditional Commit (which also includes the PSK proposal) to derive the new epoch in the traditional session. Alwen, et al. Expires 30 March 2025 [Page 6] Internet-Draft HPQMLS September 2024 Group A B Channel | | | | Commit'() | | | PresharedKeyID = | | | DeriveExtensionSecret('hpqmls_psk') | | | Commit(PreSharedKeyID) | | |-------------------------------------------------------------------->| | | | | | Commit'() | | | Commit(PreSharedKeyID) | |<--------------------------------------------------------------------+ | |<---------------------------+ Fig 1a. FULL Commit to an empty proposal list. Messages with ' are sent in the the PQ session. PreSharedKeyID identifies a PSK exported from the PQ session in the new epoch following a Commit'(). The PreSharedKeyID is implicitly included in the commit in the classical session via the PreSharedKey Proposal. Group A B Channel | | | | | Upd'(B) | | | Upd(B, f) | | |------------------------------->| | | | | | Upd'(B) | | | Upd(B, f) | |<------------------------------------------------------------------------+ | |<-------------------------------+ | | | | Commit'(Upd') | | | PresharedKeyID = | | | DeriveExtensionSecret('hpqmls_psk') | | | Commit(Upd, PreSharedKeyID) | | |------------------------------------------------------------------------>| | | | | | Commit'(Upd') | | | Commit(Upd, PreSharedKeyID) | |<------------------------------------------------------------------------+ | |<-------------------------------+ Fig 1b. FULL Commit to an Update proposal from Client B. Messages with ' are sent in the the PQ session. Alwen, et al. Expires 30 March 2025 [Page 7] Internet-Draft HPQMLS September 2024 *Remark*: Fig 1b shows Client A accepting the update proposals from Client B as a FULL Commit. The flag f in the classical update proposal Upd(B, f) indicates B's intention for a FULL Commit to whomever Commits to its proposal. 7.2. Adding a User User leaf nodes are first added to the PQ session following the sequence described in Section 3 of RFC9420 except using PQ algorithms where HPKE algorithms exist. For example, a PQ-DSA signed PQ KeyPackage, i.e. containing a PQ public key, must first be published via the Distribution Service (DS). Then the associated Commit and Welcome messages will be sent and processed in the PQ session according to Section 12 of RFC9420. The same sequence is repeated in the standard session except following the FULL Commit combining sequence where a PreSharedKeyID proposal is additionally committed. The joiner MUST issue a FULL Commit as soon as possible after joining to achieve PCS. Key Package Group A B Directory Channel | | | | | | KeyPackageB' | | | | KeyPackageB | | |<--------------------------------------------------------+ | | | | | | Commit'(Add'(KeyPackageB')) | | | | PresharedKeyID = | | | | DeriveExtensionSecret('hpqmls_psk') | | | | Commit(Add(KeyPackageB), PreSharedKeyID) | | | +---------------------------------------------------------------------------------------------------->| | | | | | Welcome' | | | | Welcome(PreSharedKeyID) | | | +----------------------------------------->| | | | | | | | | | Commit'(Add'(KeyPackageB')) | | | | Commit(Add(KeyPackageB), PreSharedKeyID) | |<----------------------------------------------------------------------------------------------------+ Figure 2: Client A adds client B to the group. Messages with ' come from the PQ session. Processing Welcome and Commit in the traditional sessio requires the PSK exported exported from the PQ session. Alwen, et al. Expires 30 March 2025 [Page 8] Internet-Draft HPQMLS September 2024 7.2.1. Welcome Message Validation Since a client must join two sessions, the Welcome messages it receives to each session must indicate that it is not sufficient to join only one or the other. Therefore, the HPQMLSInfo struct indicating the GroupID and ciphersuites of the two sessions MUST be included in the Welcome message via serialization as a GroupContext Extension in order to validate joining the combined sessions. All members MUST verify group membership is consistent in both sessions after a join and the new member MUST issue a FULL Commit as described in Fig 1b. 7.2.2. External Joins External joins are used by members who join a group without being explicitly added (via an Add-Commit sequence) by another existing member. The external user MUST join both the PQ session and the traditional session. As stated previously, the GroupInfo used to create the External Commit MUST contain the HPQMLSInfo struct. After joining, the new member MUST issue a FULL Commit as described in Fig 1b. 7.3. Removing a Group Member User removals MUST be done in both PQ and traditional sessions followed by a FULL Commit Update as as described in Fig 1b. Members MUST verify group membership is consistent in both sessions after a removal. 7.4. Application Messages HPQMLS combiner provides PQ security to the traditional MLS session. Application messages are therefore only sent in the traditional session using the encryption_secret provided by the key schedule of the traditional session according to Section 15 of RFC9420. 8. Modes of Operation Security needs vary by organizations and system-specific risk tolerance and/or constraints. While this combiner protocol targets combining a PQ session and a traditional session the degree of PQ security may be tuned depending on the use-case: i.e., as PQ/T Confidentiality Only or both PQ/T Confidentiality and PQ/T Authenticity. For PQ/T Confidentiality Only, the PQ session MUST use a PQ KEM, while for PQ authenticity, the PQ session MUST use both a PQ KEM and a PQ DSA. The modes of operation are specified by the mode flag in HPQMLSInfo struct and are listed below. Alwen, et al. Expires 30 March 2025 [Page 9] Internet-Draft HPQMLS September 2024 8.1. PQ/T Confidentiality Only The default mode of operation is PQ/T Confidentiality Only mode. This mode provides confidentiality and limited authenticity against quantum attackers. More precisely, it provides PQ authenticity against "outsiders", that is, against quantum attackers who do not have acces to (signature) secret keys of any group member. (Authenticity comes from the fact that the traditional session adds AEAD / MAC tags which are not available to outsiders with CRQC.) This mode does not prevent quantum impersonation attacks by other group members. That is, a group member with a CRQC can successfully impersonate another group member. 8.2. PQ/T Confidentiality + Authenticity The elevated mode of operation is the PQ/T Confidentiality + Authenticity mode. Under a use environment of a cryptographically relevant quantum computer (CRQC), the threat model used in the default mode would be too weak and assurance about update authenticity is required. Recall that authenticity in MLS refers to three types of guarantees: 1) that messages were sent by a member of the group provided by the computed symmetric group key used in AEAD, 2) that key updates were performed by a valid member of the group, and 3) that a message was sent by a particular user (i.e. non- repudiation) provided by digital signatures on messages. While the symmetric group key used for AEAD in the traditional session remains protected from a CRQC adversary through the PSK from the PQ session, signatures would not be secure against forgery without using a PQ DSA to sign handshake messages nor are application messages assured to have non-repudiation against a CRQC adversary. Therefore, in the PQ/ T Confidentiality + Authenticity mode, the PQ session MUST use a PQ DSA in addition to PQ KEM ciphersuites for handshake messages (the traditional session remains unchanged). This version of PQ authenticity provides PQ authenticity to the PQ session's MLS commit messages, strengthening assurance for (1) and ensuring (2). These in turn provide PQ assurance for the key schedule from which application keys are derived in the traditional session. Application keys are used in an AEAD for protection of MLS application messages and thereby inherit the PQ security. However, it should be noted that PQ non-repudation security for application messages as described by (3) is not achieved by this mode. Achieving PQ non-repudiation on application messages would require hybrid signatures in the traditional session, with considerations to options described in [I-D.hale-pquip-hybrid-signature-spectrums]. Alwen, et al. Expires 30 March 2025 [Page 10] Internet-Draft HPQMLS September 2024 9. Extension Requirements to MLS The HPQMLSInfo struct contains characterizing information to signal to users that they are participating in a hybrid session. This is necessary both functionally to allow for group synchronization and as a security measure to prevent downgrading attacks to coax users into parcipating in just one of the two sessions. The group_id, cipher_suite, and epoch from both sessions (t for the traditional session and pq for the PQ session) are used as bookkeeping values to validate and synchronize group operations. The mode is a boolean value: 0 for the default PQ/T Confidentiality Only mode and 1 for the PQ/T Confidentiality + Authenticity mode. The HPQMLSInfo struct conforms to the Safe Extensions API (see [I- D.ietf-mls-extensions]). Recall that an extension is called _safe_ if it does not modify base MLS protocol or other MLS extensions beyond using components of the Safe Extension API. This allows security analysis of our HPQMLS Combiner protocol in isolation of the security guarantees of the base MLS protocol to enable composability of guarantees. The HPMLSInfo extension struct SHALL be in the following format: struct{ ExtensionType HPQMLS; opaque extension_data; } ExtensionContent; struct{ opaque t_session_group_id; opaque PQ_session_group_id; bool mode; CipherSuite t_cipher_suite; CipherSuite pq_cipher_suite; uint64 t_epoch; uint64 pq_epoch; } HPQMLSInfo 9.1. Key Schedule The hpqmls_psk exporter key derived in the PQ session MUST be derived in accordance with the Safe Extensions API guidance (see 2.1.5 Exporting Secrets in [I-D.ietf-mls-extensions]). In particular, it SHALL NOT use the extension_secret and MUST be derived from only the epoch_secret from the key schedule in [RFC9420] (https://www.rfc- editor.org/rfc/rfc9420.html). This is to ensure forward secrecy guarantees (see Security Considerations (Section 10)). Alwen, et al. Expires 30 March 2025 [Page 11] Internet-Draft HPQMLS September 2024 Even though the hpqmls_psk PSK is not sent over the wire, members of the HPQMLS session must agree on the value of which PSK to use. In alignment with the Safe Extensions API policy for PSKs, HPQMLS PSKs used SHALL set PSKType = 3 and extension_type = HPQMLS (see Section 2.1.6 Pre-Shared Keys in [I-D.ietf-mls-extensions]). PQ Session Traditional Session ---------- ------------------- [...] DeriveExtensionSecret(epoch_secret, | "hpqmls_export") | = hpqmls_psk [...] | joiner_secret | | | | | V +----------> --> KDF.Extract [...] | | +--> DeriveSecret(., "welcome") | = welcome_secret | V ExpandWithLabel(., "epoch", GroupContext_[n], KDF.Nh) | | V epoch_secret | | +--> DeriveSecret(.,