RFC 3853

RFC 3853 🎀 S/MIME AES Requirement for SIP 💖

Okay bestie, let's talk about RFC 3853 🦋. It's titled "S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)" and it's a Standards Track doc from the Network Working Group, July 2004, by J. Peterson of Neustar 💅. It updates RFC 3261 (and the title block doesn't list anything it obsoletes), so it's basically a glow-up for SIP's security rules ✨.

---

Status of this Memo ✨

This doc is an Internet standards track protocol for the Internet community, and it's basically asking everyone to chime in with discussion and suggestions 💬. For the standardization state and status, go check the current edition of the "Internet Official Protocol Standards" (STD 1) 📋. Distribution of this memo is unlimited, so share it with your whole group chat 🌈.

Copyright Notice 🔒

Copyright (C) The Internet Society (2004) 💜.

Abstract 🌸

Okay so RFC 3261 currently names 3DES as the mandatory-to-implement ciphersuite for S/MIME in SIP 🙈. This doc updates RFC 3261's normative guidance so that S/MIME requires the Advanced Encryption Standard (AES) instead 💖. Main character energy 👑.

Table of Contents 📚

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. S/MIME Ciphersuite Requirements for SIP  . . . . . . . . . . . . 3
4. Security Considerations  . . . . . . . . . . . . . . . . . . . . 3
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   5.1.  Normative References . . . . . . . . . . . . . . . . . . . 4
   5.2.  Informative References . . . . . . . . . . . . . . . . . . 4
6. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . . 4
7. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 6

1. Introduction ✨

So SIP's spec (that's RFC 3261 [1]) currently has optional S/MIME support, and it's a normative MAY 🦋. S/MIME is defined in RFC 2633 [8] 📨. Since RFC 3261 dropped, both S/MIME and the Cryptographic Message Syntax (CMS, RFC 3369 [3]) have gotten some revisions 🔄. Ongoing work has flagged AES as an algorithm that could be used for content encryption in S/MIME 🔐.

Now, AES ([6]) is widely believed to be faster than Triple-DES (3DES, which was previously mandated for S/MIME) and to be comparably secure 🏃‍♀️💨. AES also reportedly has lower memory requirements, which makes it a great fit for mobile or embedded devices, and that's a big deal for SIP 📱🧚.

Here's the other tea ☕. SIP has a normative SHOULD for supporting Transport Layer Security (TLS, RFC 2246 [7]) 🔒. TLS in SIP requires AES too 💅. So right now, anything doing both TLS and S/MIME has to support both 3DES and AES, which is so much duplicated effort 😭. Same deal with DSS as the S/MIME signature algorithm, when the mandatory TLS ciphersuite for SIP needs RSA 🙃. Unifying the ciphersuite and signature requirements for TLS and S/MIME would make security implementations way less messy 🫶.

So the goal is to get the S/MIME requirement for SIP in sync with the ongoing S/MIME work and unify the algorithm requirements for TLS and S/MIME 💖. S/MIME hasn't really hit widespread deployment in SIP user agents yet, so updating the minimum ciphersuite won't obsolete any big existing S/MIME-for-SIP deployments. Honestly these changes will probably make S/MIME support easier 🎀. This doc updates the normative S/MIME requirements in RFC 3261 💜.

Heads up, the S/MIME working group is still working on these revisions, and this doc will keep tracking that as things evolve 👀. Starting the process in the SIP WG now gives everyone an early chance to weigh in on the proposed changes, and gives implementers a heads-up that S/MIME requirements for SIP might change 🚨.

2. Terminology 📖

In this doc, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are interpreted as described in BCP 14, RFC 2119 [2], and they indicate requirement levels for compliant SIP implementations 🔥.

3. S/MIME Ciphersuite Requirements for SIP 🔐

So this section updates the text of RFC 3261 Section 23.3, specifically the fifth bullet point 🎯. Here's what the old text reads:

o  S/MIME implementations MUST at a minimum support SHA1 as a digital
   signature algorithm, and 3DES as an encryption algorithm.  All
   other signature and encryption algorithms MAY be supported.
   Implementations can negotiate support for these algorithms with
   the "SMIMECapabilities" attribute.

And here's the glow-up 💖. S/MIME implementations MUST at minimum support RSA as a digital signature algorithm, and SHA1 as a digest algorithm [5], plus AES as an encryption algorithm (as specified in [4]) ✨. For key transport, S/MIME implementations MUST support RSA key transport, as described in section 4.2.1. of [5] 🔑. S/MIME implementations of AES MUST support 128-bit AES keys, and SHOULD support 192 and 256-bit keys 🗝️. The S/MIME spec ([8]) mandates 3DES as an encryption algorithm, DH for key encryption, and DSS as a signature algorithm 📜. In the SIP profile of S/MIME, support for 3DES, DH, and DSS is RECOMMENDED but not required 🙌. All other signature and encryption algorithms MAY be supported, and implementations can negotiate support using the "SMIMECapabilities" attribute 💫.

One more thing 🫶. Since SIP is 8-bit clean, all implementations MUST use 8-bit binary Content-Transfer-Encoding for S/MIME in SIP 💻. Implementations MAY also be able to receive base-64 Content-Transfer-Encoding 🎀.

4. Security Considerations 🚨

⚠️ Pay attention, bestie: moving the S/MIME requirement from Triple-DES to AES is not known to introduce any new security considerations 💀.

5. References 📚

5.1. Normative References 🌟

[1]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
     Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
     Session Initiation Protocol", RFC 3261, June 2002.

[2]  Bradner, S., "Key words for use in RFCs to indicate requirement
     levels", BCP 14, RFC 2119, March 1997.

[3]  Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369,
     August 2002.

[4]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
     Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC
     3565, July 2003.

[5]  Housley, R., "Cryptographic Message Syntax (CMS) Algorithms",
     RFC 3394, August 2002.

5.2. Informative References 📖

[6]  National Institute of Standards & Technology, "Advanced
     Encryption Standard (AES).", FIPS 197, November 2001.

[7]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
     2246, January 1999.

[8]  Ramsdell, B., Ed., "S/MIME Version 3.1 Message Specification",
     RFC 3851, July 2004.

6. Acknowledgments 🫶

Big thanks to Rohan Mahy, Gonzalo Camarillo, and Eric Rescorla for reviewing this doc 💖✨.

7. Author's Address 🏡

Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA  94520
US

Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI:   http://www.neustar.biz/

8. Full Copyright Statement 💅

Copyright (C) The Internet Society (2004) 🌈. This doc is subject to the rights, licenses, and restrictions in BCP 78, and except as set forth there, the authors keep all their rights 💜.

The document and the info in it are provided "AS IS", and the contributor, the organization they represent or are sponsored by (if any), the Internet Society, and the Internet Engineering Task Force all disclaim the following, in full legal-speak:

THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔍

The IETF takes no position on whether any Intellectual Property Rights or other rights claimed to cover the technology in this doc are valid or in scope, or whether a license under those rights would be available 🤷‍♀️. It also doesn't say it has independently looked for such rights. Info on the procedures for rights in RFC documents is in BCP 78 and BCP 79 📋.

Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that will be available, or the outcome of any attempt to get a general license or permission for implementers or users to use proprietary rights, can be found in the IETF online IPR repository at http://www.ietf.org/ipr 🗂️.

The IETF invites anyone to bring up any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 📬.

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society 💖✨.