RFC 3268

Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)

πŸ“… published July 2002, from ietf

RFC 3268: Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS) πŸ’–

okay bestie, let's get into it πŸŽ€ This RFC is from the Network Working Group, it's RFC 3268, and it's a Standards Track doc dated June 2002. It was written by Pete Chown from Skygate Technology. It doesn't list anything it obsoletes or updates, so it's a clean slate 🧚


Status of this Memo ✨

ok so this doc is an Internet standards track protocol for the whole Internet community, and it's basically asking for discussion and suggestions to make it better 🫢 If you want the official standardization state of this protocol, go check the current "Internet Official Protocol Standards" (STD 1) list. And distribution of this memo is unlimited, so share it with everyone πŸ’…

Copyright (C) The Internet Society (2002). All Rights Reserved. Protect your vibes πŸ’œ

Abstract ✨

this doc proposes several new ciphersuites πŸ‘‘ Right now, the symmetric ciphers TLS supports are RC2, RC4, International Data Encryption Algorithm (IDEA), Data Encryption Standard (DES), and triple DES. TLS would level up with the addition of Advanced Encryption Standard (AES) ciphersuites πŸ”₯

Overview πŸ¦‹

ok so right now TLS supports RC2, RC4, IDEA, DES, and triple DES. Adding AES [AES] ciphersuites would be a huge upgrade, and here's why πŸ’…

  1. RC2, RC4, and IDEA all come with intellectual property drama 😭 RSA Security Inc. has trademark rights in the names RC2 and RC4, and they claim that the RC4 algorithm itself is a trade secret. Ascom Systec Ltd. owns a patent on the IDEA algorithm.
  2. Triple DES is way less efficient than more modern ciphers πŸ’€
  3. Now that the AES process is finished, there's going to be commercial pressure to use the selected cipher πŸ“ˆ AES is efficient and has survived extensive cryptanalysis, so it's a super desirable choice 🌈
  4. Right now the DHE ciphersuites only allow triple DES, plus some "export" variants that don't use a satisfactory key length πŸ™ˆ But DHE is the only option that offers forward secrecy, which is a big deal ✨

This document proposes several new ciphersuites to fix all of these problems 🧚

Cipher Usage πŸ“

ok so the new ciphersuites here are very similar to these ones, defined in [TLS] πŸŽ€

TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA

all of these new ones use AES in cipher block chaining (CBC) mode πŸ’œ They also use SHA-1 [SHA-1] in an HMAC construction, as described in section 5 of [TLS] 🫢 (I know the TLS names say "SHA", but that actually refers to the modified SHA-1 version of the algorithm, so don't get tripped up πŸ™ˆ)

the ciphersuites differ in the certificate type and key exchange method πŸ¦‹ These are the options this part of the protocol uses:

CipherSuite                        Certificate type (if applicable)
                                   and key exchange algorithm

TLS_RSA_WITH_AES_128_CBC_SHA       RSA
TLS_DH_DSS_WITH_AES_128_CBC_SHA    DH_DSS
TLS_DH_RSA_WITH_AES_128_CBC_SHA    DH_RSA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA   DHE_DSS
TLS_DHE_RSA_WITH_AES_128_CBC_SHA   DHE_RSA
TLS_DH_anon_WITH_AES_128_CBC_SHA   DH_anon

TLS_RSA_WITH_AES_256_CBC_SHA       RSA
TLS_DH_DSS_WITH_AES_256_CBC_SHA    DH_DSS
TLS_DH_RSA_WITH_AES_256_CBC_SHA    DH_RSA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA   DHE_DSS
TLS_DHE_RSA_WITH_AES_256_CBC_SHA   DHE_RSA
TLS_DH_anon_WITH_AES_256_CBC_SHA   DH_anon

for what RSA, DH_DSS, DH_RSA, DHE_DSS, DHE_RSA, and DH_anon mean, check sections 7.4.2 and 7.4.3 of [TLS] πŸ“–

ok so AES supports 128, 192, and 256-bit keys πŸ”‘ But this doc only defines ciphersuites for 128-bit and 256-bit keys, just to avoid a ton of unnecessary ciphersuites πŸ™…β€β™€οΈ Rijndael actually allows 192-bit and 256-bit block sizes too, on top of the 128-bit blocks the AES process mandates 🌟 All the ciphersuites here use 128-bit blocks πŸ’–

here are the new ciphersuite definitions πŸ‘‘

CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA      = { 0x00, 0x2F };
CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA   = { 0x00, 0x30 };
CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA   = { 0x00, 0x31 };
CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA  = { 0x00, 0x32 };
CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA  = { 0x00, 0x33 };
CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA  = { 0x00, 0x34 };

CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA      = { 0x00, 0x35 };
CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA   = { 0x00, 0x36 };
CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA   = { 0x00, 0x37 };
CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA  = { 0x00, 0x38 };
CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA  = { 0x00, 0x39 };
CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA  = { 0x00, 0x3A };

part 1 is a wrap on the setup and the ciphersuites πŸ¦‹ part 2 has the Security Considerations, which are seriously important, plus the IP stuff, acknowledgements, references, and the author's address 🌈

Copyright (C) The Internet Society (2002). All Rights Reserved. πŸ’–

Okay bestie, here's the copyright tea. You're allowed to copy this document and hand it to others, and translations of it are totally fine too. You can also make derivative works that comment on or explain it, or that help with implementing it. Those can be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. ✨

However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations. The exceptions are when it's needed for developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or when it's required to translate it into languages other than English. πŸ¦‹

The limited permissions above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Forever and ever, no take-backs! πŸ’œ

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. πŸ’€

Acknowledgement 🫢

Funding for the RFC Editor function is currently provided by the Internet Society. Big thanks to them for keeping the lights on! 🌈

πŸ“¦ where this page comes from