relatively insecure environments should not write session IDs to
stable storage.
F.1.5. MD5 and SHA
TLS uses hash functions very conservatively. Where possible, both
MD5 and SHA are used in tandem to ensure that non-catastrophic flaws
in one algorithm will not break the overall protocol.
F.2. Protecting Application Data
The master_secret is hashed with the ClientHello.random and
ServerHello.random to produce unique data encryption keys and MAC
secrets for each connection.
Outgoing data is protected with a MAC before transmission. To
prevent message replay or modification attacks, the MAC is computed
from the MAC secret, the sequence number, the message length, the
message contents, and two fixed character strings. The message type
field is necessary to ensure that messages intended for one TLS
Record Layer client are not redirected to another. The sequence
number ensures that attempts to delete or reorder messages will be
detected. Since sequence numbers are 64 bits long, they should never
overflow. Messages from one party cannot be inserted into the
other’s output, since they use independent MAC secrets. Similarly,
the server-write and client-write keys are independent, so stream
cipher keys are used only once.
If an attacker does break an encryption key, all messages encrypted
with it can be read. Similarly, compromise of a MAC key can make
message modification attacks possible. Because MACs are also
encrypted, message-alteration attacks generally require breaking the
encryption algorithm as well as the MAC.
Note: MAC secrets may be larger than encryption keys, so messages can
remain tamper resistant even if encryption keys are broken.
F.3. Explicit IVs
[CBCATT] describes a chosen plaintext attack on TLS that depends on
knowing the IV for a record. Previous versions of TLS [TLS1.0] used
the CBC residue of the previous record as the IV and therefore
enabled this attack. This version uses an explicit IV in order to
protect against this attack.
F.4. Security of Composite Cipher Modes
TLS secures transmitted application data via the use of symmetric
encryption and authentication functions defined in the negotiated
ciphersuite. The objective is to protect both the integrity and
confidentiality of the transmitted data from malicious actions by
active attackers in the network. It turns out that the order in
which encryption and authentication functions are applied to the data
plays an important role for achieving this goal [ENCAUTH].
The most robust method, called encrypt-then-authenticate, first
applies encryption to the data and then applies a MAC to the
ciphertext. This method ensures that the integrity and
confidentiality goals are obtained with ANY pair of encryption and
MAC functions, provided that the former is secure against chosen
plaintext attacks and that the MAC is secure against chosen-message
attacks. TLS uses another method, called authenticate-then-encrypt,
in which first a MAC is computed on the plaintext and then the
concatenation of plaintext and MAC is encrypted. This method has
been proven secure for CERTAIN combinations of encryption functions
and MAC functions, but it is not guaranteed to be secure in general.
In particular, it has been shown that there exist perfectly secure
encryption functions (secure even in the information-theoretic sense)
that combined with any secure MAC function, fail to provide the
confidentiality goal against an active attack. Therefore, new
ciphersuites and operation modes adopted into TLS need to be analyzed
under the authenticate-then-encrypt method to verify that they
achieve the stated integrity and confidentiality goals.
Currently, the security of the authenticate-then-encrypt method has
been proven for some important cases. One is the case of stream
ciphers in which a computationally unpredictable pad of the length of
the message, plus the length of the MAC tag, is produced using a
pseudo-random generator and this pad is xor-ed with the concatenation
of plaintext and MAC tag. The other is the case of CBC mode using a
secure block cipher. In this case, security can be shown if one
applies one CBC encryption pass to the concatenation of plaintext and
MAC and uses a new, independent, and unpredictable IV for each new
pair of plaintext and MAC. In previous versions of SSL, CBC mode was
used properly EXCEPT that it used a predictable IV in the form of the
last block of the previous ciphertext. This made TLS open to chosen
plaintext attacks. This version of the protocol is immune to those
attacks. For exact details in the encryption modes proven secure,
see [ENCAUTH].
F.5. Denial of Service
TLS is susceptible to a number of denial of service (DoS) attacks.
In particular, an attacker who initiates a large number of TCP
connections can cause a server to consume large amounts of CPU doing
RSA decryption. However, because TLS is generally used over TCP, it
is difficult for the attacker to hide his point of origin if proper
TCP SYN randomization is used [SEQNUM] by the TCP stack.
Because TLS runs over TCP, it is also susceptible to a number of
denial of service attacks on individual connections. In particular,
attackers can forge RSTs, thereby terminating connections, or forge
partial TLS records, thereby causing the connection to stall. These
attacks cannot in general be defended against by a TCP-using
protocol. Implementors or users who are concerned with this class of
attack should use IPsec AH [AH-ESP] or ESP [AH-ESP].
F.6. Final Notes
For TLS to be able to provide a secure connection, both the client
and server systems, keys, and applications must be secure. In
addition, the implementation must be free of security errors.
The system is only as strong as the weakest key exchange and
authentication algorithm supported, and only trustworthy
cryptographic functions should be used. Short public keys, 40-bit
bulk encryption keys, and anonymous servers should be used with great
caution. Implementations and users must be careful when deciding
which certificates and certificate authorities are acceptable; a
dishonest certificate authority can do tremendous damage.
Normative References
[AES] National Institute of Standards and Technology,
"Specification for the Advanced Encryption Standard (AES)"
FIPS 197. November 26, 2001.
[3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To
DES," IEEE Spectrum, v. 16, n. 7, July 1979, pp. 40-41.
[DES] ANSI X3.106, "American National Standard for Information
Systems-Data Link Encryption," American National Standards
Institute, 1983.
[DSS] NIST FIPS PUB 186-2, "Digital Signature Standard,"
National Institute of Standards and Technology, U.S.
Department of Commerce, 2000.
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH
Series in Information Processing, v. 1, Konstanz:
Hartung-Gorre Verlag, 1992.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC 1321,
April 1992.
[PKCS1A] B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1:
RSA Cryptography Specifications Version 1.5", RFC 2313,
March 1998.
[PKCS1B] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards
(PKCS) #1: RSA Cryptography Specifications Version 2.1",
RFC 3447, February 2003.
[PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[RC2] Rivest, R., "A Description of the RC2(r) Encryption
Algorithm", RFC 2268, March 1998.
[SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms,
and Source Code in C, 2ed", Published by John Wiley &
Sons, Inc. 1996.
[SHA] NIST FIPS PUB 180-2, "Secure Hash Standard," National
Institute of Standards and Technology, U.S. Department of
Commerce., August 2001.
[REQ] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[TLSAES] Chown, P., "Advanced Encryption Standard (AES)
Ciphersuites for Transport Layer Security (TLS)", RFC
3268, June 2002.
[TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 3546, June 2003.
[TLSKRB] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
Suites to Transport Layer Security (TLS)", RFC 2712,
October 1999.
Informative References
[AH-ESP] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
Eastlake 3rd, D., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4305, December 2005.
[BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against
Protocols Based on RSA Encryption Standard PKCS #1" in
Advances in Cryptology -- CRYPTO’98, LNCS vol. 1462,
pages: 1-12, 1998.
[CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
Problems and Countermeasures",
http://www.openssl.org/~bodo/tls-cbc.txt.
[CBCTIME] Canvel, B., "Password Interception in a SSL/TLS Channel",
http://lasecwww.epfl.ch/memo_ssl.shtml, 2003.
[ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
for Protecting Communications (Or: How Secure is SSL?)",
Crypto 2001.
[KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,
March 2003.
[PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate
Syntax Standard," version 1.5, November 1993.
[PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message
Syntax Standard," version 1.5, November 1993.
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
June 2005.
[RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key
Cryptosystems," Communications of the ACM, v. 21, n. 2,
Feb 1978, pp. 120-126.
[SEQNUM] Bellovin, S., "Defending Against Sequence Number Attacks",
RFC 1948, May 1996.
[SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications
Corp., Feb 9, 1995.
[SSL3] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0
Protocol", Netscape Communications Corp., Nov 18, 1996.
[SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
Attacks on the Diffie-Hellman Key Agreement Method for
S/MIME", RFC 2785, March 2000.
[TCP] Hellstrom, G. and P. Jones, "RTP Payload for Text
Conversation", RFC 4103, June 2005.
[TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
practical", USENIX Security Symposium 2003.
[TLS1.0] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[X501] ITU-T Recommendation X.501: Information Technology - Open
Systems Interconnection - The Directory: Models, 1993.
[X509] ITU-T Recommendation X.509 (1997 E): Information
Technology - Open Systems Interconnection - "The Directory
- Authentication Framework". 1988.
[XDR] Srinivasan, R., "XDR: External Data Representation
Standard", RFC 1832, August 1995.
Authors’ Addresses
Working Group Chairs
Win Treese
EMail: treese@acm.org
Eric Rescorla
EMail: ekr@rtfm.com
Editors
Tim Dierks
Independent
EMail: tim@dierks.org
Eric Rescorla
RTFM, Inc.
EMail: ekr@rtfm.com
Other Contributors
Christopher Allen (co-editor of TLS 1.0)
Alacrity Ventures
EMail: ChristopherA@AlacrityManagement.com
Martin Abadi
University of California, Santa Cruz
EMail: abadi@cs.ucsc.edu
Ran Canetti
IBM
EMail: canetti@watson.ibm.com
Taher Elgamal
Securify
EMail: taher@securify.com
Anil Gangolli
EMail: anil@busybuddha.org
Kipp Hickman
Phil Karlton (co-author of SSLv3)
Paul Kocher (co-author of SSLv3)
Cryptography Research
EMail: paul@cryptography.com
Hugo Krawczyk
Technion Israel Institute of Technology
EMail: hugo@ee.technion.ac.il
Robert Relyea
Netscape Communications
EMail: relyea@netscape.com
Jim Roskind
Netscape Communications
EMail: jar@netscape.com
Michael Sabin
Dan Simon
Microsoft, Inc.
EMail: dansimon@microsoft.com
Tom Weinstein
The discussion list for the IETF TLS working group is located at the
e-mail address <ietf-tls@lists.consensus.com>. Information on the
group and information on how to subscribe to the list is at
<http://lists.consensus.com/>.
Archives of the list can be found at:
<http://www.imc.org/ietf-tls/mail-archive/>
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and 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 regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).