Higher level protocols can layer on top of the TLS Protocol
   transparently. The TLS standard, however, does not specify how
   protocols add security with TLS; the decisions on how to initiate TLS
   handshaking and how to interpret the authentication certificates
   exchanged are left up to the judgment of the designers and
   implementors of protocols which run on top of TLS.

2. Goals

   The goals of TLS Protocol, in order of their priority, are:

    1. Cryptographic security: TLS should be used to establish a secure
       connection between two parties.

    2. Interoperability: Independent programmers should be able to
       develop applications utilizing TLS that will then be able to
       successfully exchange cryptographic parameters without knowledge
       of one another's code.

    3. Extensibility: TLS seeks to provide a framework into which new
       public key and bulk encryption methods can be incorporated as
       necessary. This will also accomplish two sub-goals: to prevent




 
RFC 2246              The TLS Protocol Version 1.0          January 1999


       the need to create a new protocol (and risking the introduction
       of possible new weaknesses) and to avoid the need to implement an
       entire new security library.

    4. Relative efficiency: Cryptographic operations tend to be highly
       CPU intensive, particularly public key operations. For this
       reason, the TLS protocol has incorporated an optional session
       caching scheme to reduce the number of connections that need to
       be established from scratch. Additionally, care has been taken to
       reduce network activity.

3. Goals of this document

   This document and the TLS protocol itself are based on the SSL 3.0
   Protocol Specification as published by Netscape. The differences
   between this protocol and SSL 3.0 are not dramatic, but they are
   significant enough that TLS 1.0 and SSL 3.0 do not interoperate
   (although TLS 1.0 does incorporate a mechanism by which a TLS
   implementation can back down to SSL 3.0). This document is intended
   primarily for readers who will be implementing the protocol and those
   doing cryptographic analysis of it. The specification has been
   written with this in mind, and it is intended to reflect the needs of
   those two groups. For that reason, many of the algorithm-dependent
   data structures and rules are included in the body of the text (as
   opposed to in an appendix), providing easier access to them.

   This document is not intended to supply any details of service
   definition nor interface definition, although it does cover select
   areas of policy as they are required for the maintenance of solid
   security.

4. Presentation language

   This document deals with the formatting of data in an external
   representation. The following very basic and somewhat casually
   defined presentation syntax will be used. The syntax draws from
   several sources in its structure. Although it resembles the
   programming language "C" in its syntax and XDR [XDR] in both its
   syntax and intent, it would be risky to draw too many parallels. The
   purpose of this presentation language is to document TLS only, not to
   have general application beyond that particular goal.











 
RFC 2246              The TLS Protocol Version 1.0          January 1999


4.1. Basic block size

   The representation of all data items is explicitly specified. The
   basic data block size is one byte (i.e. 8 bits). Multiple byte data
   items are concatenations of bytes, from left to right, from top to
   bottom. From the bytestream a multi-byte item (a numeric in the
   example) is formed (using C notation) by:

       value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
               ... | byte[n-1];

   This byte ordering for multi-byte values is the commonplace network
   byte order or big endian format.