--- 1/draft-ietf-lamps-cms-mix-with-psk-04.txt 2019-06-05 13:13:13.393622149 -0700 +++ 2/draft-ietf-lamps-cms-mix-with-psk-05.txt 2019-06-05 13:13:13.453623668 -0700 @@ -1,18 +1,18 @@ INTERNET-DRAFT R. Housley Internet Engineering Task Force (IETF) Vigil Security Intended Status: Proposed Standard -Expires: 11 November 2019 10 May 2019 +Expires: 5 December 2019 5 June 2019 Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS) - + Abstract The invention of a large-scale quantum computer would pose a serious challenge for the cryptographic algorithms that are widely deployed today. The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms that could be broken by the invention of such a quantum computer. By storing communications that are protected with the CMS today, someone could decrypt them in the future when a large-scale quantum computer becomes available. Once @@ -58,47 +58,47 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Version Numbers . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. KeyTransPSKRecipientInfo . . . . . . . . . . . . . . . . . . . 6 4. KeyAgreePSKRecipientInfo . . . . . . . . . . . . . . . . . . . 7 5. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 9 6. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 14 + 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A: Key Transport with PSK Example . . . . . . . . . . . . 17 - A.1. Originator Processing Example . . . . . . . . . . . . . . 17 + A.1. Originator Processing Example . . . . . . . . . . . . . . 18 A.2. ContentInfo and AuthEnvelopedData . . . . . . . . . . . . 20 A.3. Recipient Processing Example . . . . . . . . . . . . . . . 22 Appendix B: Key Agreement with PSK Example . . . . . . . . . . . . 23 B.1. Originator Processing Example . . . . . . . . . . . . . . 23 B.2. ContentInfo and AuthEnvelopedData . . . . . . . . . . . . 26 B.3. Recipient Processing Example . . . . . . . . . . . . . . . 27 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction The invention of a large-scale quantum computer would pose a serious challenge for the cryptographic algorithms that are widely deployed today. It is an open question whether or not it is feasible to build a large-scale quantum computer, and if so, when that might happen. However, if such a quantum computer is invented, many of the cryptographic algorithms and the security protocols that use them would become vulnerable. - The Cryptographic Message Syntax (CMS) [RFC5652][RFC5803] supports + The Cryptographic Message Syntax (CMS) [RFC5652][RFC5083] supports key transport and key agreement algorithms that could be broken by the invention of a large-scale quantum computer [C2PQ]. These algorithms include RSA [RFC8017], Diffie-Hellman [RFC2631], and Elliptic Curve Diffie-Hellman [RFC5753]. As a result, an adversary that stores CMS-protected communications today, could decrypt those communications in the future when a large-scale quantum computer becomes available. Once quantum-secure key management algorithms are available, the CMS will be extended to support them, if the existing syntax does not @@ -606,25 +606,37 @@ KeyAgreePSKRecipientInfo. Doing so would make the content vulnerable to the future invention of a large-scale quantum computer. Implementers should not send the same content in different messages, one using a quantum-resistant key management algorithm and the other using a non-quantum-resistant key management algorithm, even if the content-encryption key is generated independently. Doing so may allow an eavesdropper to correlate the messages, making the content vulnerable to the future invention of a large-scale quantum computer. + This specification does not require that PSK is known only by the + sender and recipients. The PSK may be known to a group. Since + confidentiality depends on the key transport or key agreement + algorithm, knowledge of the PSK by other parties does not enable + eavesdropping. However, group members can record the traffic of + other members, and then decrypt it if they ever gain access to a + large-scale quantum computer. Also, when many parties know the PSK, + there are many opportunities for theft of the PSK by an attacker. + Once an attacker has the PSK, they can decrypt stored traffic if they + ever gain access to a large-scale quantum computer in the same manner + as a legitimate group member. + Sound cryptographic key hygiene is to use a key for one and only one purpose. Use of the recipient's public key for both the traditional CMS and the PSK-mixing variation specified in this document would be - a violations of this principle; however, there is no known way for an - attacker to take advantage of this situation. However, an + a violation of this principle; however, there is no known way for an + attacker to take advantage of this situation. That said, an application should enforce separation whenever possible. For example, an purpose identifier for use in the X.509 extended key usage certificate extension [RFC5280] could be identified in the future to indicate that a public key should only be used in conjunction with a PSK, or only without. Implementations must randomly generate key-derivation keys as well as the content-encryption keys or content-authenticated-encryption keys. Also, the generation of public/private key pairs for the key transport and key agreement algorithms rely on a random numbers. The @@ -709,21 +721,25 @@ Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, 2015. 10.2. Informative References [AES] National Institute of Standards and Technology, FIPS Pub 197: Advanced Encryption Standard (AES), 26 November 2001. [C2PQ] Hoffman, P., "The Transition from Classical to Post- Quantum Cryptography", work-in-progress, draft-hoffman- - c2pq-03, February 2018. + c2pq-04, August 2018. + + [H2019] Hammell, J., "Re: [lamps] WG Last Call for draft-ietf- + lamps-cms-mix-with-psk", , 27 May 2019. [IANA-MOD] https://www.iana.org/assignments/smi-numbers/smi- numbers.xhtml#security-smime-0. [IANA-SMIME] https://www.iana.org/assignments/smi-numbers/smi- numbers.xhtml#security-smime. [IANA-ORI] https://www.iana.org/assignments/smi-numbers/smi- numbers.xhtml#security-smime-13. @@ -1017,24 +1033,24 @@ Appendix B: Key Agreement with PSK Example This example shows the establishment of an AES-256 content-encryption key using: - a pre-shared key of 256 bits; - key agreement using ECDH on curve P-384 and X9.63 KDF with SHA-384; - key derivation using HKDF with SHA-384; and - key wrap using AES-256-KEYWRAP. - In real-world use, the originator would treat themselves as an additional - recipient by performing key agreement with their own static public key - the ephemeral private key generated for this message. This is omited in - an attempt to simplify the example. + In real-world use, the originator would treat themselves as an + additional recipient by performing key agreement with their own + static public key and the ephemeral private key generated for this + message. This is omited in an attempt to simplify the example. B.1. Originator Processing Example The pre-shared key known to Alice and Bob: 4aa53cbf500850dd583a5d9821605c6fa228fb5917f87c1c078660214e2d83e4 The identifier assigned to the pre-shared key is: ptf-kmc:216840110121 Alice randomly generates a content-encryption key: @@ -1247,18 +1263,26 @@ The resutling plaintext content is: 48656c6c6f2c20776f726c6421 Acknowledgements Many thanks to Burt Kaliski, Panos Kampanakis, Jim Schaad, Sean Turner, and Daniel Van Geest for their review and insightful comments. They have greatly improved the design, clarity, and implementation guidance. + The security properties provided by the mechanisms specified in this + document can be validated using formal methods. A ProVerif proof in + [H2019] shows that an attacker with a large-scale quantum computer + that is capable of breaking the Diffie-Hellman key agreement + algorithm cannot disrupt the delivery of the content-encryption key + to the recipient and the attacker cannot learn the content-encryption + key from the protocol exchange. + Author's Address Russ Housley Vigil Security, LLC 516 Dranesville Road Herndon, VA 20170 USA EMail: housley@vigilsec.com