Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 5246

The Transport Layer Security (TLS) Protocol Version 1.2

Pages: 104
Obsoletes:  326843464366
Obsoleted by:  8446
Updates:  4492
Updated by:  574658786176746575077568762776857905791984479155
Part 5 of 5 – Pages 85 to 104
First   Prev   None

ToP   noToC   RFC5246 - Page 85   prevText

Appendix D. Implementation Notes

The TLS protocol cannot prevent many common security mistakes. This section provides several recommendations to assist implementors.

D.1. Random Number Generation and Seeding

TLS requires a cryptographically secure pseudorandom number generator (PRNG). Care must be taken in designing and seeding PRNGs. PRNGs based on secure hash operations, most notably SHA-1, are acceptable, but cannot provide more security than the size of the random number generator state. To estimate the amount of seed material being produced, add the number of bits of unpredictable information in each seed byte. For example, keystroke timing values taken from a PC compatible's 18.2 Hz timer provide 1 or 2 secure bits each, even though the total size of the counter value is 16 bits or more. Seeding a 128-bit PRNG would thus require approximately 100 such timer values. [RANDOM] provides guidance on the generation of random values.

D.2. Certificates and Authentication

Implementations are responsible for verifying the integrity of certificates and should generally support certificate revocation messages. Certificates should always be verified to ensure proper signing by a trusted Certificate Authority (CA). The selection and addition of trusted CAs should be done very carefully. Users should be able to view information about the certificate and root CA.

D.3. Cipher Suites

TLS supports a range of key sizes and security levels, including some that provide no or minimal security. A proper implementation will probably not support many cipher suites. For instance, anonymous Diffie-Hellman is strongly discouraged because it cannot prevent man- in-the-middle attacks. Applications should also enforce minimum and maximum key sizes. For example, certificate chains containing 512- bit RSA keys or signatures are not appropriate for high-security applications.

D.4. Implementation Pitfalls

Implementation experience has shown that certain parts of earlier TLS specifications are not easy to understand, and have been a source of interoperability and security problems. Many of these areas have
ToP   noToC   RFC5246 - Page 86
   been clarified in this document, but this appendix contains a short
   list of the most important things that require special attention from

   TLS protocol issues:

   -  Do you correctly handle handshake messages that are fragmented to
      multiple TLS records (see Section 6.2.1)? Including corner cases
      like a ClientHello that is split to several small fragments? Do
      you fragment handshake messages that exceed the maximum fragment
      size? In particular, the certificate and certificate request
      handshake messages can be large enough to require fragmentation.

   -  Do you ignore the TLS record layer version number in all TLS
      records before ServerHello (see Appendix E.1)?

   -  Do you handle TLS extensions in ClientHello correctly, including
      omitting the extensions field completely?

   -  Do you support renegotiation, both client and server initiated?
      While renegotiation is an optional feature, supporting it is
      highly recommended.

   -  When the server has requested a client certificate, but no
      suitable certificate is available, do you correctly send an empty
      Certificate message, instead of omitting the whole message (see
      Section 7.4.6)?

   Cryptographic details:

   -  In the RSA-encrypted Premaster Secret, do you correctly send and
      verify the version number? When an error is encountered, do you
      continue the handshake to avoid the Bleichenbacher attack (see

   -  What countermeasures do you use to prevent timing attacks against
      RSA decryption and signing operations (see Section

   -  When verifying RSA signatures, do you accept both NULL and missing
      parameters (see Section 4.7)? Do you verify that the RSA padding
      doesn't have additional data after the hash value?  [FI06]

   -  When using Diffie-Hellman key exchange, do you correctly strip
      leading zero bytes from the negotiated key (see Section 8.1.2)?

   -  Does your TLS client check that the Diffie-Hellman parameters sent
      by the server are acceptable (see Section F.1.1.3)?
ToP   noToC   RFC5246 - Page 87
   -  How do you generate unpredictable IVs for CBC mode ciphers (see

   -  Do you accept long CBC mode padding (up to 255 bytes; see Section

   -  How do you address CBC mode timing attacks (Section

   -  Do you use a strong and, most importantly, properly seeded random
      number generator (see Appendix D.1) for generating the premaster
      secret (for RSA key exchange), Diffie-Hellman private values, the
      DSA "k" parameter, and other security-critical values?

Appendix E. Backward Compatibility

E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0

Since there are various versions of TLS (1.0, 1.1, 1.2, and any future versions) and SSL (2.0 and 3.0), means are needed to negotiate the specific protocol version to use. The TLS protocol provides a built-in mechanism for version negotiation so as not to bother other protocol components with the complexities of version selection. TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use compatible ClientHello messages; thus, supporting all of them is relatively easy. Similarly, servers can easily handle clients trying to use future versions of TLS as long as the ClientHello format remains compatible, and the client supports the highest protocol version available in the server. A TLS 1.2 client who wishes to negotiate with such older servers will send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in ClientHello.client_version. If the server does not support this version, it will respond with a ServerHello containing an older version number. If the client agrees to use this version, the negotiation will proceed as appropriate for the negotiated protocol. If the version chosen by the server is not supported by the client (or not acceptable), the client MUST send a "protocol_version" alert message and close the connection. If a TLS server receives a ClientHello containing a version number greater than the highest version supported by the server, it MUST reply according to the highest version supported by the server. A TLS server can also receive a ClientHello containing a version number smaller than the highest supported version. If the server wishes to negotiate with old clients, it will proceed as appropriate
ToP   noToC   RFC5246 - Page 88
   for the highest version supported by the server that is not greater
   than ClientHello.client_version.  For example, if the server supports
   TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will
   proceed with a TLS 1.0 ServerHello.  If server supports (or is
   willing to use) only versions greater than client_version, it MUST
   send a "protocol_version" alert message and close the connection.

   Whenever a client already knows the highest protocol version known to
   a server (for example, when resuming a session), it SHOULD initiate
   the connection in that native protocol.

   Note: some server implementations are known to implement version
   negotiation incorrectly.  For example, there are buggy TLS 1.0
   servers that simply close the connection when the client offers a
   version newer than TLS 1.0.  Also, it is known that some servers will
   refuse the connection if any TLS extensions are included in
   ClientHello.  Interoperability with such buggy servers is a complex
   topic beyond the scope of this document, and may require multiple
   connection attempts by the client.

   Earlier versions of the TLS specification were not fully clear on
   what the record layer version number (TLSPlaintext.version) should
   contain when sending ClientHello (i.e., before it is known which
   version of the protocol will be employed).  Thus, TLS servers
   compliant with this specification MUST accept any value {03,XX} as
   the record layer version number for ClientHello.

   TLS clients that wish to negotiate with older servers MAY send any
   value {03,XX} as the record layer version number.  Typical values
   would be {03,00}, the lowest version number supported by the client,
   and the value of ClientHello.client_version.  No single value will
   guarantee interoperability with all old servers, but this is a
   complex topic beyond the scope of this document.

E.2. Compatibility with SSL 2.0

TLS 1.2 clients that wish to support SSL 2.0 servers MUST send version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message MUST contain the same version number as would be used for ordinary ClientHello, and MUST encode the supported TLS cipher suites in the CIPHER-SPECS-DATA field as described below. Warning: The ability to send version 2.0 CLIENT-HELLO messages will be phased out with all due haste, since the newer ClientHello format provides better mechanisms for moving to newer versions and negotiating extensions. TLS 1.2 clients SHOULD NOT support SSL 2.0.
ToP   noToC   RFC5246 - Page 89
   However, even TLS servers that do not support SSL 2.0 MAY accept
   version 2.0 CLIENT-HELLO messages.  The message is presented below in
   sufficient detail for TLS server implementors; the true definition is
   still assumed to be [SSL2].

   For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same
   way as a ClientHello with a "null" compression method and no
   extensions.  Note that this message MUST be sent directly on the
   wire, not wrapped as a TLS record.  For the purposes of calculating
   Finished and CertificateVerify, the msg_length field is not
   considered to be a part of the handshake message.

      uint8 V2CipherSpec[3];
      struct {
          uint16 msg_length;
          uint8 msg_type;
          Version version;
          uint16 cipher_spec_length;
          uint16 session_id_length;
          uint16 challenge_length;
          V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
          opaque session_id[V2ClientHello.session_id_length];
          opaque challenge[V2ClientHello.challenge_length;
      } V2ClientHello;

      The highest bit MUST be 1; the remaining bits contain the length
      of the following data in bytes.

      This field, in conjunction with the version field, identifies a
      version 2 ClientHello message.  The value MUST be 1.

      Equal to ClientHello.client_version.

      This field is the total length of the field cipher_specs.  It
      cannot be zero and MUST be a multiple of the V2CipherSpec length

      This field MUST have a value of zero for a client that claims to
      support TLS 1.2.
ToP   noToC   RFC5246 - Page 90
      The length in bytes of the client's challenge to the server to
      authenticate itself.  Historically, permissible values are between
      16 and 32 bytes inclusive.  When using the SSLv2 backward-
      compatible handshake the client SHOULD use a 32-byte challenge.

      This is a list of all CipherSpecs the client is willing and able
      to use.  In addition to the 2.0 cipher specs defined in [SSL2],
      this includes the TLS cipher suites normally sent in
      ClientHello.cipher_suites, with each cipher suite prefixed by a
      zero byte.  For example, the TLS cipher suite {0x00,0x0A} would be
      sent as {0x00,0x00,0x0A}.

      This field MUST be empty.

      Corresponds to ClientHello.random.  If the challenge length is
      less than 32, the TLS server will pad the data with leading (note:
      not trailing) zero bytes to make it 32 bytes long.

   Note: Requests to resume a TLS session MUST use a TLS client hello.

E.3. Avoiding Man-in-the-Middle Version Rollback

When TLS clients fall back to Version 2.0 compatibility mode, they MUST use special PKCS#1 block formatting. This is done so that TLS servers will reject Version 2.0 sessions with TLS-capable clients. When a client negotiates SSL 2.0 but also supports TLS, it MUST set the right-hand (least-significant) 8 random bytes of the PKCS padding (not including the terminal null of the padding) for the RSA encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY to 0x03 (the other padding bytes are random). When a TLS-capable server negotiates SSL 2.0 it SHOULD, after decrypting the ENCRYPTED-KEY-DATA field, check that these 8 padding bytes are 0x03. If they are not, the server SHOULD generate a random value for SECRET-KEY-DATA, and continue the handshake (which will eventually fail since the keys will not match). Note that reporting the error situation to the client could make the server vulnerable to attacks described in [BLEI].
ToP   noToC   RFC5246 - Page 91

Appendix F. Security Analysis

The TLS protocol is designed to establish a secure connection between a client and a server communicating over an insecure channel. This document makes several traditional assumptions, including that attackers have substantial computational resources and cannot obtain secret information from sources outside the protocol. Attackers are assumed to have the ability to capture, modify, delete, replay, and otherwise tamper with messages sent over the communication channel. This appendix outlines how TLS has been designed to resist a variety of attacks.

F.1. Handshake Protocol

The handshake protocol is responsible for selecting a cipher spec and generating a master secret, which together comprise the primary cryptographic parameters associated with a secure session. The handshake protocol can also optionally authenticate parties who have certificates signed by a trusted certificate authority.

F.1.1. Authentication and Key Exchange

TLS supports three authentication modes: authentication of both parties, server authentication with an unauthenticated client, and total anonymity. Whenever the server is authenticated, the channel is secure against man-in-the-middle attacks, but completely anonymous sessions are inherently vulnerable to such attacks. Anonymous servers cannot authenticate clients. If the server is authenticated, its certificate message must provide a valid certificate chain leading to an acceptable certificate authority. Similarly, authenticated clients must supply an acceptable certificate to the server. Each party is responsible for verifying that the other's certificate is valid and has not expired or been revoked. The general goal of the key exchange process is to create a pre_master_secret known to the communicating parties and not to attackers. The pre_master_secret will be used to generate the master_secret (see Section 8.1). The master_secret is required to generate the Finished messages, encryption keys, and MAC keys (see Sections 7.4.9 and 6.3). By sending a correct Finished message, parties thus prove that they know the correct pre_master_secret.
F.1.1.1. Anonymous Key Exchange
Completely anonymous sessions can be established using Diffie-Hellman for key exchange. The server's public parameters are contained in the server key exchange message, and the client's are sent in the
ToP   noToC   RFC5246 - Page 92
   client key exchange message.  Eavesdroppers who do not know the
   private values should not be able to find the Diffie-Hellman result
   (i.e., the pre_master_secret).

   Warning: Completely anonymous connections only provide protection
   against passive eavesdropping.  Unless an independent tamper-proof
   channel is used to verify that the Finished messages were not
   replaced by an attacker, server authentication is required in
   environments where active man-in-the-middle attacks are a concern.

F.1.1.2. RSA Key Exchange and Authentication
With RSA, key exchange and server authentication are combined. The public key is contained in the server's certificate. Note that compromise of the server's static RSA key results in a loss of confidentiality for all sessions protected under that static key. TLS users desiring Perfect Forward Secrecy should use DHE cipher suites. The damage done by exposure of a private key can be limited by changing one's private key (and certificate) frequently. After verifying the server's certificate, the client encrypts a pre_master_secret with the server's public key. By successfully decoding the pre_master_secret and producing a correct Finished message, the server demonstrates that it knows the private key corresponding to the server certificate. When RSA is used for key exchange, clients are authenticated using the certificate verify message (see Section 7.4.8). The client signs a value derived from all preceding handshake messages. These handshake messages include the server certificate, which binds the signature to the server, and ServerHello.random, which binds the signature to the current handshake process.
F.1.1.3. Diffie-Hellman Key Exchange with Authentication
When Diffie-Hellman key exchange is used, the server can either supply a certificate containing fixed Diffie-Hellman parameters or use the server key exchange message to send a set of temporary Diffie-Hellman parameters signed with a DSA or RSA certificate. Temporary parameters are hashed with the hello.random values before signing to ensure that attackers do not replay old parameters. In either case, the client can verify the certificate or signature to ensure that the parameters belong to the server. If the client has a certificate containing fixed Diffie-Hellman parameters, its certificate contains the information required to complete the key exchange. Note that in this case the client and server will generate the same Diffie-Hellman result (i.e.,
ToP   noToC   RFC5246 - Page 93
   pre_master_secret) every time they communicate.  To prevent the
   pre_master_secret from staying in memory any longer than necessary,
   it should be converted into the master_secret as soon as possible.
   Client Diffie-Hellman parameters must be compatible with those
   supplied by the server for the key exchange to work.

   If the client has a standard DSA or RSA certificate or is
   unauthenticated, it sends a set of temporary parameters to the server
   in the client key exchange message, then optionally uses a
   certificate verify message to authenticate itself.

   If the same DH keypair is to be used for multiple handshakes, either
   because the client or server has a certificate containing a fixed DH
   keypair or because the server is reusing DH keys, care must be taken
   to prevent small subgroup attacks.  Implementations SHOULD follow the
   guidelines found in [SUBGROUP].

   Small subgroup attacks are most easily avoided by using one of the
   DHE cipher suites and generating a fresh DH private key (X) for each
   handshake.  If a suitable base (such as 2) is chosen, g^X mod p can
   be computed very quickly; therefore, the performance cost is
   minimized.  Additionally, using a fresh key for each handshake
   provides Perfect Forward Secrecy.  Implementations SHOULD generate a
   new X for each handshake when using DHE cipher suites.

   Because TLS allows the server to provide arbitrary DH groups, the
   client should verify that the DH group is of suitable size as defined
   by local policy.  The client SHOULD also verify that the DH public
   exponent appears to be of adequate size.  [KEYSIZ] provides a useful
   guide to the strength of various group sizes.  The server MAY choose
   to assist the client by providing a known group, such as those
   defined in [IKEALG] or [MODP].  These can be verified by simple

F.1.2. Version Rollback Attacks

Because TLS includes substantial improvements over SSL Version 2.0, attackers may try to make TLS-capable clients and servers fall back to Version 2.0. This attack can occur if (and only if) two TLS- capable parties use an SSL 2.0 handshake. Although the solution using non-random PKCS #1 block type 2 message padding is inelegant, it provides a reasonably secure way for Version 3.0 servers to detect the attack. This solution is not secure against attackers who can brute-force the key and substitute a new ENCRYPTED-KEY-DATA message containing the same key (but with normal padding) before the application-specified wait threshold has expired. Altering the padding of the least-significant 8 bytes of the PKCS
ToP   noToC   RFC5246 - Page 94
   padding does not impact security for the size of the signed hashes
   and RSA key lengths used in the protocol, since this is essentially
   equivalent to increasing the input block size by 8 bytes.

F.1.3. Detecting Attacks Against the Handshake Protocol

An attacker might try to influence the handshake exchange to make the parties select different encryption algorithms than they would normally choose. For this attack, an attacker must actively change one or more handshake messages. If this occurs, the client and server will compute different values for the handshake message hashes. As a result, the parties will not accept each others' Finished messages. Without the master_secret, the attacker cannot repair the Finished messages, so the attack will be discovered.

F.1.4. Resuming Sessions

When a connection is established by resuming a session, new ClientHello.random and ServerHello.random values are hashed with the session's master_secret. Provided that the master_secret has not been compromised and that the secure hash operations used to produce the encryption keys and MAC keys are secure, the connection should be secure and effectively independent from previous connections. Attackers cannot use known encryption keys or MAC secrets to compromise the master_secret without breaking the secure hash operations. Sessions cannot be resumed unless both the client and server agree. If either party suspects that the session may have been compromised, or that certificates may have expired or been revoked, it should force a full handshake. An upper limit of 24 hours is suggested for session ID lifetimes, since an attacker who obtains a master_secret may be able to impersonate the compromised party until the corresponding session ID is retired. Applications that may be run in relatively insecure environments should not write session IDs to stable storage.

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 key, the sequence number, the message length, the
ToP   noToC   RFC5246 - Page 95
   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 keys.  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 keys 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 cipher suite. 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.
ToP   noToC   RFC5246 - Page 96
   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 cipher
   suites 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
   pseudorandom generator and this pad is exclusive-ORed 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 versions of TLS prior to
   1.1, 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 for 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 DoS 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] or ESP [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.
ToP   noToC   RFC5246 - Page 97
   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 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] National Institute of Standards and Technology, "Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher", NIST Special Publication 800-67, May 2004. [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. [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [PKCS1] Jonsson, J. and 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. [SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2nd ed.", Published by John Wiley & Sons, Inc. 1996. [SHS] NIST FIPS PUB 180-2, "Secure Hash Standard", National Institute of Standards and Technology, U.S. Department of Commerce, August 2002.
ToP   noToC   RFC5246 - Page 98
   [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.

   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
              Information technology - Abstract Syntax Notation One
              (ASN.1): Specification of basic notation.

   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
              Information technology - ASN.1 encoding Rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules

Informative References

[AEAD] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, January 2008. [AH] Kent, S., "IP Authentication Header", RFC 4302, 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", [CBCTIME] Canvel, B., Hiltgen, A., Vaudenay, S., and M. Vuagnoux, "Password Interception in a SSL/TLS Channel", Advances in Cryptology -- CRYPTO 2003, LNCS vol. 2729, 2003. [CCM] "NIST Special Publication 800-38C: The CCM Mode for Authentication and Confidentiality", SP800-38C.pdf [DES] National Institute of Standards and Technology, "Data Encryption Standard (DES)", FIPS PUB 46-3, October 1999.
ToP   noToC   RFC5246 - Page 99
   [DSS-3]    NIST FIPS PUB 186-3 Draft, "Digital Signature Standard",
              National Institute of Standards and Technology, U.S.
              Department of Commerce, 2006.

   [ECDSA]    American National Standards Institute, "Public Key
              Cryptography for the Financial Services Industry: The
              Elliptic Curve Digital Signature Algorithm (ECDSA)", ANS
              X9.62-2005, November 2005.

   [ENCAUTH]  Krawczyk, H., "The Order of Encryption and Authentication
              for Protecting Communications (Or: How Secure is SSL?)",
              Crypto 2001.

   [ESP]      Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
              4303, December 2005.

   [FI06]     Hal Finney, "Bleichenbacher's RSA signature forgery based
              on implementation error", mailing
              list, 27 August 2006,

   [GCM]      Dworkin, M., NIST Special Publication 800-38D,
              "Recommendation for Block Cipher Modes of Operation:
              Galois/Counter Mode (GCM) and GMAC", November 2007.

   [IKEALG]   Schiller, J., "Cryptographic Algorithms for Use in the
              Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
              December 2005.

   [KEYSIZ]   Orman, H. and P. Hoffman, "Determining Strengths For
              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
              RFC 3766, April 2004.

   [KPR03]    Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
              Sessions in SSL/TLS",,
              March 2003.

   [MODP]     Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
              Diffie-Hellman groups for Internet Key Exchange (IKE)",
              RFC 3526, May 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.
ToP   noToC   RFC5246 - Page 100
   [RANDOM]   Eastlake, D., 3rd, Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              June 2005.

   [RFC3749]  Hollenbeck, S., "Transport Layer Security Protocol
              Compression Methods", RFC 3749, May 2004.

   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 4366, April 2006.

   [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. Freier, 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]      Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, September 1981.

   [TIMING]   Boneh, D., Brumley, D., "Remote timing attacks are
              practical", USENIX Security Symposium 2003.

   [TLSAES]   Chown, P., "Advanced Encryption Standard (AES)
              Ciphersuites for Transport Layer Security (TLS)", RFC
              3268, June 2002.

   [TLSECC]   Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
              for Transport Layer Security (TLS)", RFC 4492, May 2006.

   [TLSEXT]   Eastlake, D., 3rd, "Transport Layer Security (TLS)
              Extensions:  Extension Definitions", Work in Progress,
              February 2008.
ToP   noToC   RFC5246 - Page 101
   [TLSPGP]   Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport
              Layer Security (TLS) Authentication", RFC 5081, November

   [TLSPSK]   Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key
              Ciphersuites for Transport Layer Security (TLS)", RFC
              4279, December 2005.

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

   [TLS1.1]   Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

   [X501]     ITU-T Recommendation X.501: Information Technology - Open
              Systems Interconnection - The Directory: Models, 1993.

   [XDR]      Eisler, M., Ed., "XDR: External Data Representation
              Standard", STD 67, RFC 4506, May 2006.

Working Group Information

   The discussion list for the IETF TLS working group is located at the
   e-mail address <>. Information on the group and
   information on how to subscribe to the list is at

   Archives of the list can be found at:


Christopher Allen (co-editor of TLS 1.0) Alacrity Ventures Martin Abadi University of California, Santa Cruz Steven M. Bellovin Columbia University Simon Blake-Wilson BCI
ToP   noToC   RFC5246 - Page 102
   Ran Canetti

   Pete Chown
   Skygate Technology Ltd

   Taher Elgamal

   Pasi Eronen

   Anil Gangolli

   Kipp Hickman

   Alfred Hoenes

   David Hopwood
   Independent Consultant

   Phil Karlton (co-author of SSLv3)

   Paul Kocher (co-author of SSLv3)
   Cryptography Research

   Hugo Krawczyk

   Jan Mikkelsen

   Magnus Nystrom
   RSA Security

   Robert Relyea
   Netscape Communications
ToP   noToC   RFC5246 - Page 103
   Jim Roskind
   Netscape Communications

   Michael Sabin

   Dan Simon
   Microsoft, Inc.

   Tom Weinstein

   Tim Wright

Editors' Addresses

Tim Dierks Independent EMail: Eric Rescorla RTFM, Inc. EMail:
ToP   noToC   RFC5246 - Page 104
Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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

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

   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