< draft-ietf-tls-rfc2246-bis-04.txt		draft-ietf-tls-rfc2246-bis-05.txt >
	Tim Dierks |		Tim Dierks |
	Independent |		Independent |
	Eric Rescorla |		Eric Rescorla |
	INTERNET-DRAFT RTFM, Inc. |		INTERNET-DRAFT RTFM, Inc. |
	<draft-ietf-tls-rfc2246-bis-04.txt> April 2003 (Expires October 2003) |		<draft-ietf-tls-rfc2246-bis-05.txt> June 2003 (Expires December 2003) |
	The TLS Protocol		The TLS Protocol
	Version 1.1 |		Version 1.1 |
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with |		This document is an Internet-Draft and is in full conformance with |
	all provisions of Section 10 of RFC2026. Internet-Drafts are working |		all provisions of Section 10 of RFC2026. Internet-Drafts are working |
	documents of the Internet Engineering Task Force (IETF), its areas, |		documents of the Internet Engineering Task Force (IETF), its areas, |
	and its working groups. Note that other groups may also distribute |		and its working groups. Note that other groups may also distribute |
	skipping to change at page 89, line ? ¶		skipping to change at page 90, line ? ¶
	Security Considerations 75		Security Considerations 75
	References 75		References 75
	Credits 77		Credits 77
	Comments 78		Comments 78
	Full Copyright Statement 80		Full Copyright Statement 80
	Change history |		Change history |
	Note: Change bars in this draft are from RFC 2246, not draft-00 |		Note: Change bars in this draft are from RFC 2246, not draft-00 |
			26-Jun-03 ekr@rtfm.com |
			* Incorporated Last Call comments from Franke Marcus, Jack Lloyd, |
			Brad Wetmore, and others. |
	22-Apr-03 ekr@rtfm.com |		22-Apr-03 ekr@rtfm.com |
	* coverage of the Vaudenay, Boneh-Brumley, and KPR attacks |		* coverage of the Vaudenay, Boneh-Brumley, and KPR attacks |
	* cleaned up IV text a bit. |		* cleaned up IV text a bit. |
	* Added discussion of Denial of Service attacks. |		* Added discussion of Denial of Service attacks. |
	|		|
	11-Feb-02 ekr@rtfm.com |		11-Feb-02 ekr@rtfm.com |
	* Clarified the behavior of empty certificate lists [Nelson Bolyard] |		* Clarified the behavior of empty certificate lists [Nelson Bolyard] |
	* Added text explaining the security implications of authenticate |		* Added text explaining the security implications of authenticate |
	then encrypt. |		then encrypt. |
	* Cleaned up the explicit IV text. |		* Cleaned up the explicit IV text. |
	skipping to change at page 89, line ? ¶		skipping to change at page 90, line ? ¶
	uint8 key_material_length;		uint8 key_material_length;
	IsExportable is_exportable;		IsExportable is_exportable;
	MACAlgorithm mac_algorithm;		MACAlgorithm mac_algorithm;
	uint8 hash_size;		uint8 hash_size;
	CompressionMethod compression_algorithm;		CompressionMethod compression_algorithm;
	opaque master_secret[48];		opaque master_secret[48];
	opaque client_random[32];		opaque client_random[32];
	opaque server_random[32];		opaque server_random[32];
	} SecurityParameters;		} SecurityParameters;
	The record layer will use the security parameters to generate the		The record layer will use the security parameters to generate the |
	following six items:		following four items:
	client write MAC secret		client write MAC secret
	server write MAC secret		server write MAC secret
	client write key		client write key
	server write key		server write key
	The client write parameters are used by the server when receiving and		The client write parameters are used by the server when receiving and
	processing records and vice-versa. The algorithm used for generating		processing records and vice-versa. The algorithm used for generating
	these items from the security parameters is described in section 6.3.		these items from the security parameters is described in section 6.3.
	skipping to change at page 89, line ? ¶		skipping to change at page 90, line ? ¶
	this will also contain whatever the necessary state information |		this will also contain whatever the necessary state information |
	is to allow the stream to continue to encrypt or decrypt data.		is to allow the stream to continue to encrypt or decrypt data.
	MAC secret		MAC secret
	The MAC secret for this connection as generated above.		The MAC secret for this connection as generated above.
	sequence number		sequence number
	Each connection state contains a sequence number, which is		Each connection state contains a sequence number, which is
	maintained separately for read and write states. The sequence |		maintained separately for read and write states. The sequence |
	number MUST be set to zero whenever a connection state is made		number MUST be set to zero whenever a connection state is made
	the active state. Sequence numbers are of type uint64 and may not		the active state. Sequence numbers are of type uint64 and may not |
	exceed 2^64-1. A sequence number is incremented after each		exceed 2^64-1. Sequence numbers do not wrap. If a TLS |
			implementation would need to wrap a sequence number it must |
			renegotiate instead. A sequence number is incremented after each
	record: specifically, the first record which is transmitted under |		record: specifically, the first record which is transmitted under |
	a particular connection state MUST use sequence number 0.		a particular connection state MUST use sequence number 0.
	6.2. Record layer		6.2. Record layer
	The TLS Record Layer receives uninterpreted data from higher layers		The TLS Record Layer receives uninterpreted data from higher layers
	in non-empty blocks of arbitrary size.		in non-empty blocks of arbitrary size.
	6.2.1. Fragmentation		6.2.1. Fragmentation
	skipping to change at page 89, line ? ¶		skipping to change at page 90, line ? ¶
	length		length
	The length (in bytes) of the following TLSPlaintext.fragment.		The length (in bytes) of the following TLSPlaintext.fragment.
	The length should not exceed 2^14.		The length should not exceed 2^14.
	fragment		fragment
	The application data. This data is transparent and treated as an		The application data. This data is transparent and treated as an
	independent block to be dealt with by the higher level protocol		independent block to be dealt with by the higher level protocol
	specified by the type field.		specified by the type field.
	Note: Data of different TLS Record layer content types MAY be |		Note: Data of different TLS Record layer content types MAY be |
	interleaved. Application data is generally of lower precedence		interleaved. Application data is generally of lower precedence |
	for transmission than other content types.		for transmission than other content types and therefore handshake |
			records may be held if application data is pending. However, |
			records MUST be delivered to the network in the same order as |
			they are protected by the record layer. |
	6.2.2. Record compression and decompression		6.2.2. Record compression and decompression
	All records are compressed using the compression algorithm defined in		All records are compressed using the compression algorithm defined in
	the current session state. There is always an active compression		the current session state. There is always an active compression
	algorithm; however, initially it is defined as		algorithm; however, initially it is defined as
	CompressionMethod.null. The compression algorithm translates a		CompressionMethod.null. The compression algorithm translates a
	TLSPlaintext structure into a TLSCompressed structure. Compression		TLSPlaintext structure into a TLSCompressed structure. Compression
	functions are initialized with default state information whenever a		functions are initialized with default state information whenever a
	connection state is made active.		connection state is made active.
	skipping to change at page 89, line ? ¶		skipping to change at page 90, line ? ¶
	block-ciphered struct {		block-ciphered struct {
	opaque IV[CipherSpec.block_length]; |		opaque IV[CipherSpec.block_length]; |
	opaque content[TLSCompressed.length];		opaque content[TLSCompressed.length];
	opaque MAC[CipherSpec.hash_size];		opaque MAC[CipherSpec.hash_size];
	uint8 padding[GenericBlockCipher.padding_length];		uint8 padding[GenericBlockCipher.padding_length];
	uint8 padding_length;		uint8 padding_length;
	} GenericBlockCipher;		} GenericBlockCipher;
	The MAC is generated as described in Section 6.2.3.1.		The MAC is generated as described in Section 6.2.3.1.
	encryptedIV |		IV |
	Unlike previous versions of SSL and TLS, TLS 1.1 uses an explicit |		Unlike previous versions of SSL and TLS, TLS 1.1 uses an explicit |
	IV in order to prevent the attacks described by [CBCATT]. |		IV in order to prevent the attacks described by [CBCATT]. |
	We recommend the following equivalently strong procedures. |		We recommend the following equivalently strong procedures. |
	For clarity we use the following notation. |		For clarity we use the following notation. |
	IV -- the transmitted value of the IV field in the |		IV -- the transmitted value of the IV field in the |
	GenericBlockCipher structure. |		GenericBlockCipher structure. |
	CBC residue -- the last ciphertext block of the previous record |		CBC residue -- the last ciphertext block of the previous record |
	mask -- the actual value which the cipher XORs with the |		mask -- the actual value which the cipher XORs with the |
	plaintext prior to encryption of the first cipher block |		plaintext prior to encryption of the first cipher block |
	skipping to change at page 89, line ? ¶		skipping to change at page 90, line ? ¶
	padding		padding
	Padding that is added to force the length of the plaintext to be		Padding that is added to force the length of the plaintext to be
	an integral multiple of the block cipher's block length. The |		an integral multiple of the block cipher's block length. The |
	padding MAY be any length up to 255 bytes long, as long as it		padding MAY be any length up to 255 bytes long, as long as it
	results in the TLSCiphertext.length being an integral multiple of		results in the TLSCiphertext.length being an integral multiple of
	the block length. Lengths longer than necessary might be		the block length. Lengths longer than necessary might be
	desirable to frustrate attacks on a protocol based on analysis of		desirable to frustrate attacks on a protocol based on analysis of
	the lengths of exchanged messages. Each uint8 in the padding data |		the lengths of exchanged messages. Each uint8 in the padding data |
	vector MUST be filled with the padding length value. The receiver |		vector MUST be filled with the padding length value. The receiver |
	MUST check this padding and SHOULD use the bad_record_mac alert |		MUST check this padding and SHOULD use the bad_record_mac alert |
	to indivate padding errors.		to indicate padding errors.
	padding_length		padding_length
	The padding length MUST be such that the total size of the |		The padding length MUST be such that the total size of the |
	GenericBlockCipher structure is a multiple of the cipher's block		GenericBlockCipher structure is a multiple of the cipher's block
	length. Legal values range from zero to 255, inclusive. This		length. Legal values range from zero to 255, inclusive. This
	length specifies the length of the padding field exclusive of the		length specifies the length of the padding field exclusive of the
	padding_length field itself.		padding_length field itself.
	The encrypted data length (TLSCiphertext.length) is one more than the		The encrypted data length (TLSCiphertext.length) is one more than the
	sum of TLSCompressed.length, CipherSpec.hash_size, and		sum of TLSCompressed.length, CipherSpec.hash_size, and
	padding_length.		padding_length.
	Example: If the block length is 8 bytes, the content length		Example: If the block length is 8 bytes, the content length
	(TLSCompressed.length) is 61 bytes, and the MAC length is 20		(TLSCompressed.length) is 61 bytes, and the MAC length is 20 |
	bytes, the length before padding is 82 bytes. Thus, the		bytes, the length before padding is 82 bytes (this does not |
	padding length modulo 8 must be equal to 6 in order to make		include the IV, which may or may not be encrypted, as |
	the total length an even multiple of 8 bytes (the block		discussed above). Thus, the padding length modulo 8 must be
	length). The padding length can be 6, 14, 22, and so on,		equal to 6 in order to make the total length an even multiple
	through 254. If the padding length were the minimum necessary,		of 8 bytes (the block length). The padding length can be 6,
	6, the padding would be 6 bytes, each containing the value 6.		14, 22, and so on, through 254. If the padding length were the
	Thus, the last 8 octets of the GenericBlockCipher before block		minimum necessary, 6, the padding would be 6 bytes, each
	encryption would be xx 06 06 06 06 06 06 06, where xx is the		containing the value 6. Thus, the last 8 octets of the
	last octet of the MAC.		GenericBlockCipher before block encryption would be xx 06 06
			06 06 06 06 06, where xx is the last octet of the MAC.
	Note: With block ciphers in CBC mode (Cipher Block Chaining), |		Note: With block ciphers in CBC mode (Cipher Block Chaining), |
	it is critical that the entire plaintext of the record be known |		it is critical that the entire plaintext of the record be known |
	before any ciphertext is transmitted. Otherwise it is possible |		before any ciphertext is transmitted. Otherwise it is possible |
	for the attacker to mount the attack described in [CBCATT]. |		for the attacker to mount the attack described in [CBCATT]. |
	Implementation Note: Canvel et. al. [CBCTIME] have demonstrated a |		Implementation Note: Canvel et. al. [CBCTIME] have demonstrated a |
	timing attack on CBC padding based on the time required to |		timing attack on CBC padding based on the time required to |
	compute the MAC. In order to defend against this attack, |		compute the MAC. In order to defend against this attack, |
	implementations MUST ensure that record processing time is |		implementations MUST ensure that record processing time is |
	skipping to change at page 89, line ? ¶		skipping to change at page 90, line ? ¶
	believed to be large enough to be exploitable due to the large |		believed to be large enough to be exploitable due to the large |
	block size of existing MACs and the small size of the timing |		block size of existing MACs and the small size of the timing |
	signal.		signal.
	6.3. Key calculation		6.3. Key calculation
	The Record Protocol requires an algorithm to generate keys, and MAC |		The Record Protocol requires an algorithm to generate keys, and MAC |
	secrets from the security parameters provided by the handshake		secrets from the security parameters provided by the handshake
	protocol.		protocol.
	The master secret is hashed into a sequence of secure bytes, which		The master secret is hashed into a sequence of secure bytes, which |
	are assigned to the MAC secrets, keys, and non-export IVs required by		are assigned to the MAC secrets and keys required by the current
	the current connection state (see Appendix A.6). CipherSpecs require		connection state (see Appendix A.6). CipherSpecs require a client
	a client write MAC secret, a server write MAC secret, a client write |		write MAC secret, a server write MAC secret, a client write key, and |
	key, and a server write key, which are generated from the master |		a server write key, which are generated from the master secret in |
	secret in that order. Unused values are empty.		that order. Unused values are empty.
	When generating keys and MAC secrets, the master secret is used as an		When generating keys and MAC secrets, the master secret is used as an
	entropy source, and the random values provide unencrypted salt |		entropy source, and the random values provide unencrypted salt |
	material for exportable ciphers.		material for exportable ciphers.
	To generate the key material, compute		To generate the key material, compute
	key_block = PRF(SecurityParameters.master_secret,		key_block = PRF(SecurityParameters.master_secret,
	"key expansion",		"key expansion",
	SecurityParameters.server_random +		SecurityParameters.server_random +
	skipping to change at page 89, line ? ¶		skipping to change at page 90, line ? ¶
	correct. This message is always fatal.		correct. This message is always fatal.
	decryption_failed		decryption_failed
	This alert MAY be returned if a TLSCiphertext decrypted in an |		This alert MAY be returned if a TLSCiphertext decrypted in an |
	invalid way: either it wasn't an even multiple of the block |		invalid way: either it wasn't an even multiple of the block |
	length, or its padding values, when checked, weren't correct. |		length, or its padding values, when checked, weren't correct. |
	This message is always fatal. |		This message is always fatal. |
	NB: Differentiating between bad_record_mac and decryption_failed |		NB: Differentiating between bad_record_mac and decryption_failed |
	alerts may permit certain attacks against CBC mode as used in TLS |		alerts may permit certain attacks against CBC mode as used in TLS |
	[CBCATTACK]. It is preferable to uniformly use the bad_record_mac |		[CBCATT]. It is preferable to uniformly use the bad_record_mac |
	alert to hide the specific type of the error. |		alert to hide the specific type of the error. |
	record_overflow		record_overflow
	A TLSCiphertext record was received which had a length more than		A TLSCiphertext record was received which had a length more than
	2^14+2048 bytes, or a record decrypted to a TLSCompressed record		2^14+2048 bytes, or a record decrypted to a TLSCompressed record
	with more than 2^14+1024 bytes. This message is always fatal.		with more than 2^14+1024 bytes. This message is always fatal.
	decompression_failure		decompression_failure
	The decompression function received improper input (e.g. data		The decompression function received improper input (e.g. data
	that would expand to excessive length). This message is always		that would expand to excessive length). This message is always
	skipping to change at page 89, line ? ¶		skipping to change at page 90, line ? ¶
	case client_key_exchange: ClientKeyExchange;		case client_key_exchange: ClientKeyExchange;
	case finished: Finished;		case finished: Finished;
	} body;		} body;
	} Handshake;		} Handshake;
	The handshake protocol messages are presented below in the order they |		The handshake protocol messages are presented below in the order they |
	MUST be sent; sending handshake messages in an unexpected order		MUST be sent; sending handshake messages in an unexpected order
	results in a fatal error. Unneeded handshake messages can be omitted,		results in a fatal error. Unneeded handshake messages can be omitted,
	however. Note one exception to the ordering: the Certificate message		however. Note one exception to the ordering: the Certificate message
	is used twice in the handshake (from server to client, then from		is used twice in the handshake (from server to client, then from
	client to server), but described only in its first position. The one		client to server), but described only in its first position. The one
	message which is not bound by these ordering rules in the Hello		message which is not bound by these ordering rules is the Hello |
	Request message, which can be sent at any time, but which should be		Request message, which can be sent at any time, but which should be
	ignored by the client if it arrives in the middle of a handshake.		ignored by the client if it arrives in the middle of a handshake.
	7.4.1. Hello messages		7.4.1. Hello messages
	The hello phase messages are used to exchange security enhancement		The hello phase messages are used to exchange security enhancement
	capabilities between the client and server. When a new session		capabilities between the client and server. When a new session
	begins, the Record Layer's connection state encryption, hash, and		begins, the Record Layer's connection state encryption, hash, and
	compression algorithms are initialized to null. The current		compression algorithms are initialized to null. The current
	connection state is used for renegotiation messages.		connection state is used for renegotiation messages.
	skipping to change at page 89, line ? ¶		skipping to change at page 90, line ? ¶
	Forward compatibility note:		Forward compatibility note:
	In the interests of forward compatibility, it is permitted for a		In the interests of forward compatibility, it is permitted for a
	client hello message to include extra data after the compression |		client hello message to include extra data after the compression |
	methods. This data MUST be included in the handshake hashes, but		methods. This data MUST be included in the handshake hashes, but
	must otherwise be ignored. This is the only handshake message for		must otherwise be ignored. This is the only handshake message for
	which this is legal; for all other messages, the amount of data |		which this is legal; for all other messages, the amount of data |
	in the message MUST match the description of the message		in the message MUST match the description of the message
	precisely.		precisely.
	Note: For the intended use of trailing data in the ClientHello, see RFC |		Note: For the intended use of trailing data in the ClientHello, see RFC |
	XXXX [Extensions]. |		3546 [TLSEXT]. |
	7.4.1.3. Server hello		7.4.1.3. Server hello
	When this message will be sent:		When this message will be sent:
	The server will send this message in response to a client hello		The server will send this message in response to a client hello
	message when it was able to find an acceptable set of algorithms.		message when it was able to find an acceptable set of algorithms.
	If it cannot find such a match, it will respond with a handshake		If it cannot find such a match, it will respond with a handshake
	failure alert.		failure alert.
	Structure of this message:		Structure of this message:
	skipping to change at page 89, line ? ¶		skipping to change at page 90, line ? ¶
	select (KeyExchangeAlgorithm) {		select (KeyExchangeAlgorithm) {
	case diffie_hellman:		case diffie_hellman:
	ServerDHParams params;		ServerDHParams params;
	Signature signed_params;		Signature signed_params;
	case rsa:		case rsa:
	ServerRSAParams params;		ServerRSAParams params;
	Signature signed_params;		Signature signed_params;
	};		};
	} ServerKeyExchange;		} ServerKeyExchange;
			struct { |
			select (KeyExchangeAlgorithm) { |
			case diffie_hellman: |
			ServerDHParams params; |
			case rsa: |
			ServerRSAParams params; |
			}; |
			} ServerParams; |
	params		params
	The server's key exchange parameters.		The server's key exchange parameters.
	signed_params		signed_params
	For non-anonymous key exchanges, a hash of the corresponding		For non-anonymous key exchanges, a hash of the corresponding
	params value, with the signature appropriate to that hash		params value, with the signature appropriate to that hash
	applied.		applied.
	md5_hash		md5_hash
	MD5(ClientHello.random + ServerHello.random + ServerParams);		MD5(ClientHello.random + ServerHello.random + ServerParams);
	sha_hash		sha_hash
	SHA(ClientHello.random + ServerHello.random + ServerParams);		SHA(ClientHello.random + ServerHello.random + ServerParams);
	enum { anonymous, rsa, dsa } SignatureAlgorithm;		enum { anonymous, rsa, dsa } SignatureAlgorithm;
	select (SignatureAlgorithm)		select (SignatureAlgorithm) |
	{ case anonymous: struct { };		{ |
			case anonymous: struct { }; |
	case rsa:		case rsa:
	digitally-signed struct {		digitally-signed struct {
	opaque md5_hash[16];		opaque md5_hash[16];
	opaque sha_hash[20];		opaque sha_hash[20];
	};		};
	case dsa:		case dsa:
	digitally-signed struct {		digitally-signed struct {
	opaque sha_hash[20];		opaque sha_hash[20];
	};		};
	} Signature;		} Signature;
	skipping to change at page 89, line ? ¶		skipping to change at page 90, line ? ¶
	} ClientCertificateType;		} ClientCertificateType;
	opaque DistinguishedName<1..2^16-1>;		opaque DistinguishedName<1..2^16-1>;
	struct {		struct {
	ClientCertificateType certificate_types<1..2^8-1>;		ClientCertificateType certificate_types<1..2^8-1>;
	DistinguishedName certificate_authorities<0..2^16-1>; |		DistinguishedName certificate_authorities<0..2^16-1>; |
	} CertificateRequest;		} CertificateRequest;
	certificate_types		certificate_types
	This field is a list of the types of certificates requested,		This field is a list of the types of certificates requested, |
	sorted in order of the server's preference.		sorted in order of the server's preference. |
	certificate_authorities		certificate_authorities
	A list of the distinguished names of acceptable certificate		A list of the distinguished names of acceptable certificate
	authorities. These distinguished names may specify a desired		authorities. These distinguished names may specify a desired
	distinguished name for a root CA or for a subordinate CA;		distinguished name for a root CA or for a subordinate CA;
	thus, this message can be used both to describe known roots |		thus, this message can be used both to describe known roots |
	and a desired authorization space. If the |		and a desired authorization space. If the |
	certificate_authorities list is empty then the client MAY |		certificate_authorities list is empty then the client MAY |
	send any certificate of the appropriate |		send any certificate of the appropriate |
	ClientCertificateType, unless there is some external |		ClientCertificateType, unless there is some external |
	arrangement to the contrary. |		arrangement to the contrary. |
	Note: values listed as RESERVED may not be used. They were used in |		Note: Values listed as RESERVED may not be used. They were used in |
	SSLv3.		SSLv3.
	Note: DistinguishedName is derived from [X509].		Note: DistinguishedName is derived from [X509].
	Note: It is a fatal handshake_failure alert for an anonymous server to		Note: It is a fatal handshake_failure alert for an anonymous server to
	request client identification.		request client authentication. |
	7.4.5. Server hello done		7.4.5. Server hello done
	When this message will be sent:		When this message will be sent:
	The server hello done message is sent by the server to indicate		The server hello done message is sent by the server to indicate
	the end of the server hello and associated messages. After		the end of the server hello and associated messages. After
	sending this message the server will wait for a client response.		sending this message the server will wait for a client response.
	Meaning of this message:		Meaning of this message:
	This message means that the server is done sending messages to		This message means that the server is done sending messages to
	skipping to change at page 89, line ? ¶		skipping to change at page 90, line ? ¶
	implementations do not include the the length bytes, encoding the |		implementations do not include the the length bytes, encoding the |
	RSA encrypted data directly in the ClientKeyExchange message. |		RSA encrypted data directly in the ClientKeyExchange message. |
	This specification requires correct encoding of the |		This specification requires correct encoding of the |
	EncryptedPreMasterSecret complete with length bytes. The |		EncryptedPreMasterSecret complete with length bytes. The |
	resulting PDU is incompatible with many SSLv3 implementations. |		resulting PDU is incompatible with many SSLv3 implementations. |
	Implementors upgrading from SSLv3 must modify their |		Implementors upgrading from SSLv3 must modify their |
	implementations to generate and accept the correct encoding. |		implementations to generate and accept the correct encoding. |
	Implementors who wish to be compatible with both SSLv3 and TLS |		Implementors who wish to be compatible with both SSLv3 and TLS |
	should make their implementation's behavior dependent on the |		should make their implementation's behavior dependent on the |
	protocol version.		protocol version. |
	Implementation Note: It is now known that remote timing-based attacks |		Implementation Note: It is now known that remote timing-based attacks |
	on SSL are possible, at least when the client and server are on |		on SSL are possible, at least when the client and server are on |
	the same LAN. Accordingly, implementations which use static RSA |		the same LAN. Accordingly, implementations which use static RSA |
	keys SHOULD use RSA blinding or some other anti-timing technique, |		keys SHOULD use RSA blinding or some other anti-timing technique, |
	as described in [TIMING]. |		as described in [TIMING].
	Note: The version number in the PreMasterSecret is that offered by the |		Note: The version number in the PreMasterSecret is that offered by the |
	client, NOT the version negotiated for the connection. This |		client, NOT the version negotiated for the connection. This |
	feature is designed to prevent rollback attacks. Unfortunately, |		feature is designed to prevent rollback attacks. Unfortunately, |
	many implementations use the negotiated version instead and |		many implementations use the negotiated version instead and |
	therefore checking the version number may lead to failure to |		therefore checking the version number may lead to failure to |
	interoperate with such incorrect client implementations. Client |		interoperate with such incorrect client implementations. Client |
	implementations MUST Server implementations MAY check the version |		implementations MUST and Server implementations MAY check the |
	number. In practice, since there are no significant known |		version number. In practice, since there are no significant known |
	security differences between TLS and SSLv3, rollback to SSLv3 is |		security differences between TLS and SSLv3, rollback to SSLv3 is |
	not believed to be a serious security risk. Note that if servers |		not believed to be a serious security risk. Note that if servers |
	choose to to check the version number, they should randomize the |		choose to to check the version number, they should randomize the |
	PreMasterSecret in case of error, rather than generate an alert, |		PreMasterSecret in case of error, rather than generate an alert, |
	in order to avoid variants on the Bleichenbacher attack. [KPR03]		in order to avoid variants on the Bleichenbacher attack. [KPR03]
	7.4.7.2. Client Diffie-Hellman public value		7.4.7.2. Client Diffie-Hellman public value
	Meaning of this message:		Meaning of this message:
	This structure conveys the client's Diffie-Hellman public value		This structure conveys the client's Diffie-Hellman public value
	skipping to change at page 89, line ? ¶		skipping to change at page 90, line ? ¶
	Structure of this message:		Structure of this message:
	struct {		struct {
	Signature signature;		Signature signature;
	} CertificateVerify;		} CertificateVerify;
	The Signature type is defined in 7.4.3.		The Signature type is defined in 7.4.3.
	CertificateVerify.signature.md5_hash		CertificateVerify.signature.md5_hash
	MD5(handshake_messages);		MD5(handshake_messages);
	Certificate.signature.sha_hash		CertificateVerify.signature.sha_hash |
	SHA(handshake_messages);		SHA(handshake_messages);
	Here handshake_messages refers to all handshake messages sent or		Here handshake_messages refers to all handshake messages sent or
	received starting at client hello up to but not including this		received starting at client hello up to but not including this
	message, including the type and length fields of the handshake		message, including the type and length fields of the handshake
	messages. This is the concatenation of all the Handshake structures		messages. This is the concatenation of all the Handshake structures
	as defined in 7.4 exchanged thus far.		as defined in 7.4 exchanged thus far.
	7.4.9. Finished		7.4.9. Finished
	skipping to change at page 89, line ? ¶		skipping to change at page 90, line ? ¶
	8.1. Computing the master secret		8.1. Computing the master secret
	For all key exchange methods, the same algorithm is used to convert		For all key exchange methods, the same algorithm is used to convert
	the pre_master_secret into the master_secret. The pre_master_secret		the pre_master_secret into the master_secret. The pre_master_secret
	should be deleted from memory once the master_secret has been		should be deleted from memory once the master_secret has been
	computed.		computed.
	master_secret = PRF(pre_master_secret, "master secret",		master_secret = PRF(pre_master_secret, "master secret",
	ClientHello.random + ServerHello.random)		ClientHello.random + ServerHello.random)
	[0..47];		[0..47];
	The master secret is always exactly 48 bytes in length. The length of		The master secret is always exactly 48 bytes in length. The length of
	the premaster secret will vary depending on key exchange method.		the premaster secret will vary depending on key exchange method.
	8.1.1. RSA		8.1.1. RSA
	When RSA is used for server authentication and key exchange, a		When RSA is used for server authentication and key exchange, a
	48-byte pre_master_secret is generated by the client, encrypted under		48-byte pre_master_secret is generated by the client, encrypted under
	the server's public key, and sent to the server. The server uses its		the server's public key, and sent to the server. The server uses its
	private key to decrypt the pre_master_secret. Both parties then		private key to decrypt the pre_master_secret. Both parties then
	convert the pre_master_secret into the master_secret, as specified		convert the pre_master_secret into the master_secret, as specified
	above.		above.
	RSA digital signatures are performed using PKCS #1 [PKCS1] block type		RSA digital signatures are performed using PKCS #1 [PKCS1] block type
	1. RSA public key encryption is performed using PKCS #1 block type 2.		1. RSA public key encryption is performed using PKCS #1 block type 2.
	8.1.2. Diffie-Hellman		8.1.2. Diffie-Hellman
	A conventional Diffie-Hellman computation is performed. The		A conventional Diffie-Hellman computation is performed. The
	negotiated key (Z) is used as the pre_master_secret, and is converted		negotiated key (Z) is used as the pre_master_secret, and is converted
	into the master_secret, as specified above.		into the master_secret, as specified above. Leading 0 bytes of Z are |
			stripped before it is used as the pre_master_secret.
	Note: Diffie-Hellman parameters are specified by the server, and may		Note: Diffie-Hellman parameters are specified by the server, and may
	be either ephemeral or contained within the server's certificate.		be either ephemeral or contained within the server's certificate.
	9. Mandatory Cipher Suites		9. Mandatory Cipher Suites
	In the absence of an application profile standard specifying		In the absence of an application profile standard specifying
	otherwise, a TLS compliant application MUST implement the cipher |		otherwise, a TLS compliant application MUST implement the cipher |
	suite TLS_RSA_WITH_3DES_EDE_CBC_SHA. |		suite TLS_RSA_WITH_3DES_EDE_CBC_SHA. |
	skipping to change at page 89, line ? ¶		skipping to change at page 90, line ? ¶
	select (KeyExchangeAlgorithm) {		select (KeyExchangeAlgorithm) {
	case diffie_hellman:		case diffie_hellman:
	ServerDHParams params;		ServerDHParams params;
	Signature signed_params;		Signature signed_params;
	case rsa:		case rsa:
	ServerRSAParams params;		ServerRSAParams params;
	Signature signed_params;		Signature signed_params;
	};		};
	} ServerKeyExchange;		} ServerKeyExchange;
	enum { anonymous, rsa, dsa } SignatureAlgorithm;		enum { anonymous, rsa, dsa } SignatureAlgorithm; |
			struct { |
			select (KeyExchangeAlgorithm) { |
			case diffie_hellman: |
			ServerDHParams params; |
			case rsa: |
			ServerRSAParams params; |
			}; |
			} ServerParams; |
	select (SignatureAlgorithm)		select (SignatureAlgorithm)
	{ case anonymous: struct { };		{ case anonymous: struct { };
	case rsa:		case rsa:
	digitally-signed struct {		digitally-signed struct {
	opaque md5_hash[16];		opaque md5_hash[16];
	opaque sha_hash[20];		opaque sha_hash[20];
	};		};
	case dsa:		case dsa:
	digitally-signed struct {		digitally-signed struct {
	skipping to change at page 89, line ? ¶		skipping to change at page 90, line ? ¶
	DH_DSS_EXPORT DH with DSS-based certificates DH = 512 bits		DH_DSS_EXPORT DH with DSS-based certificates DH = 512 bits
	DH_RSA DH with RSA-based certificates None		DH_RSA DH with RSA-based certificates None
	DH_RSA_EXPORT DH with RSA-based certificates DH = 512 bits,		DH_RSA_EXPORT DH with RSA-based certificates DH = 512 bits,
	RSA = none		RSA = none
	NULL No key exchange N/A		NULL No key exchange N/A
	RSA RSA key exchange None		RSA RSA key exchange None
	RSA_EXPORT RSA key exchange RSA = 512 bits		RSA_EXPORT RSA key exchange RSA = 512 bits
	Key size limit		Key size limit
	The key size limit gives the size of the largest public key that		The key size limit gives the size of the largest public key that
	can be legally used for encryption in cipher suites that are		can be legally used for encryption or key agreement in |
	exportable.		cipher suites that are exportable. |
	Key Expanded Effective IV Block		Key Expanded Effective IV Block
	Cipher Type Material Key Material Key Bits Size Size		Cipher Type Material Key Material Key Bits Size Size
	NULL * Stream 0 0 0 0 N/A		NULL * Stream 0 0 0 0 N/A
	IDEA_CBC Block 16 16 128 8 8		IDEA_CBC Block 16 16 128 8 8
	RC2_CBC_40 * Block 5 16 40 8 8		RC2_CBC_40 * Block 5 16 40 8 8
	RC4_40 * Stream 5 16 40 0 N/A		RC4_40 * Stream 5 16 40 0 N/A
	RC4_128 Stream 16 16 128 0 N/A		RC4_128 Stream 16 16 128 0 N/A
	DES40_CBC * Block 5 8 40 8 8		DES40_CBC * Block 5 8 40 8 8
	skipping to change at page 89, line ? ¶		skipping to change at page 90, line ? ¶
	For historical reasons and in order to avoid a profligate consumption		For historical reasons and in order to avoid a profligate consumption
	of reserved port numbers, application protocols which are secured by |		of reserved port numbers, application protocols which are secured by |
	TLS 1.1, TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same		TLS 1.1, TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same
	connection port: for example, the https protocol (HTTP secured by SSL		connection port: for example, the https protocol (HTTP secured by SSL
	or TLS) uses port 443 regardless of which security protocol it is		or TLS) uses port 443 regardless of which security protocol it is
	using. Thus, some mechanism must be determined to distinguish and		using. Thus, some mechanism must be determined to distinguish and
	negotiate among the various protocols.		negotiate among the various protocols.
	TLS versions 1.1, 1.0, and SSL 3.0 are very similar; thus, supporting |		TLS versions 1.1, 1.0, and SSL 3.0 are very similar; thus, supporting |
	both is easy. TLS clients who wish to negotiate with such older |		both is easy. TLS clients who wish to negotiate with such older |
	servers should send client hello messages using the SSL 3.0 record		servers SHOULD send client hello messages using the SSL 3.0 record |
	format and client hello structure, sending {3, 2} for the version |		format and client hello structure, sending {3, 2} for the version |
	field to note that they support TLS 1.1. If the server supports only |		field to note that they support TLS 1.1. If the server supports only |
	TLS 1.0 or SSL 3.0, it will respond with a downrev 3.0 server hello; |		TLS 1.0 or SSL 3.0, it will respond with a downrev 3.0 server hello; |
	if it supports TLS 1.1 it will respond with a TLS 1.1 server hello. |		if it supports TLS 1.1 it will respond with a TLS 1.1 server hello. |
	The negotiation then proceeds as appropriate for the negotiated		The negotiation then proceeds as appropriate for the negotiated
	protocol.		protocol.
	Similarly, a TLS 1.1 server which wishes to interoperate with TLS |		Similarly, a TLS 1.1 server which wishes to interoperate with TLS |
	1.0 or SSL 3.0 clients SHOULD accept SSL 3.0 client hello messages |		1.0 or SSL 3.0 clients SHOULD accept SSL 3.0 client hello messages |
	and respond with a SSL 3.0 server hello if an SSL 3.0 client hello |		and respond with a SSL 3.0 server hello if an SSL 3.0 client hello |
	with a version field of {3, 0} is received, denoting that this client |		with a version field of {3, 0} is received, denoting that this client |
	does not support TLS. Similarly, if a SSL 3.0 or TLS 1.0 hello with a |		does not support TLS. Similarly, if a SSL 3.0 or TLS 1.0 hello with a |
	version field of {3, 1} is received, the server SHOULD respond with a |		version field of {3, 1} is received, the server SHOULD respond with a |
	TLS 1.0 hello with a version field of {3, 1}.		TLS 1.0 hello with a version field of {3, 1}.
	Whenever a client already knows the highest protocol known to a		Whenever a client already knows the highest protocol known to a |
	server (for example, when resuming a session), it should initiate the		server (for example, when resuming a session), it SHOULD initiate the
	connection in that native protocol.		connection in that native protocol.
	TLS 1.1 clients that support SSL Version 2.0 servers must send SSL |		TLS 1.1 clients that support SSL Version 2.0 servers MUST send SSL |
	Version 2.0 client hello messages [SSL2]. TLS servers should accept		Version 2.0 client hello messages [SSL2]. TLS servers SHOULD accept
	either client hello format if they wish to support SSL 2.0 clients on		either client hello format if they wish to support SSL 2.0 clients on
	the same connection port. The only deviations from the Version 2.0		the same connection port. The only deviations from the Version 2.0
	specification are the ability to specify a version with a value of		specification are the ability to specify a version with a value of
	three and the support for more ciphering types in the CipherSpec.		three and the support for more ciphering types in the CipherSpec.
	Warning: The ability to send Version 2.0 client hello messages will be		Warning: The ability to send Version 2.0 client hello messages will be
	phased out with all due haste. Implementors should make every		phased out with all due haste. Implementors SHOULD make every |
	effort to move forward as quickly as possible. Version 3.0		effort to move forward as quickly as possible. Version 3.0
	provides better mechanisms for moving to newer versions.		provides better mechanisms for moving to newer versions.
	The following cipher specifications are carryovers from SSL Version		The following cipher specifications are carryovers from SSL Version
	2.0. These are assumed to use RSA for key exchange and		2.0. These are assumed to use RSA for key exchange and
	authentication.		authentication.
	V2CipherSpec TLS_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 };		V2CipherSpec TLS_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 };
	V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };		V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
	V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 };		V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 };
	V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5		V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5
	= { 0x04,0x00,0x80 };		= { 0x04,0x00,0x80 };
	V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 };		V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 };
	V2CipherSpec TLS_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 };		V2CipherSpec TLS_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 };
	V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };		V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };
	Cipher specifications native to TLS can be included in Version 2.0		Cipher specifications native to TLS can be included in Version 2.0
	client hello messages using the syntax below. Any V2CipherSpec		client hello messages using the syntax below. Any V2CipherSpec
	element with its first byte equal to zero will be ignored by Version		element with its first byte equal to zero will be ignored by Version |
	2.0 servers. Clients sending any of the above V2CipherSpecs should		2.0 servers. Clients sending any of the above V2CipherSpecs SHOULD
	also include the TLS equivalent (see Appendix A.5):		also include the TLS equivalent (see Appendix A.5):
	V2CipherSpec (see TLS name) = { 0x00, CipherSuite };		V2CipherSpec (see TLS name) = { 0x00, CipherSuite };
	E.1. Version 2 client hello		E.1. Version 2 client hello
	The Version 2.0 client hello message is presented below using this		The Version 2.0 client hello message is presented below using this
	document's presentation model. The true definition is still assumed |		document's presentation model. The true definition is still assumed |
	to be the SSL Version 2.0 specification. Note that this message must |		to be the SSL Version 2.0 specification. Note that this message MUST |
	be sent directly on the wire, not wrapped as an SSLv3 record		be sent directly on the wire, not wrapped as an SSLv3 record
	uint8 V2CipherSpec[3];		uint8 V2CipherSpec[3];
	struct {		struct {
	uint16 msg_length; |		uint16 msg_length; |
	uint8 msg_type;		uint8 msg_type;
	Version version;		Version version;
	uint16 cipher_spec_length;		uint16 cipher_spec_length;
	uint16 session_id_length;		uint16 session_id_length;
	uint16 challenge_length;		uint16 challenge_length;
	V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];		V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
	opaque session_id[V2ClientHello.session_id_length];		opaque session_id[V2ClientHello.session_id_length];
	opaque challenge[V2ClientHello.challenge_length; |		opaque challenge[V2ClientHello.challenge_length; |
	} V2ClientHello;		} V2ClientHello;
	msg_length |		msg_length |
	This field is the length of the following data in bytes. The high |		This field is the length of the following data in bytes. The high |
	bit must be 1 and is not part of the length. |		bit MUST be 1 and is not part of the length. |
	msg_type		msg_type
	This field, in conjunction with the version field, identifies a		This field, in conjunction with the version field, identifies a |
	version 2 client hello message. The value should be one (1).		version 2 client hello message. The value SHOULD be one (1).
	version		version
	The highest version of the protocol supported by the client		The highest version of the protocol supported by the client
	(equals ProtocolVersion.version, see Appendix A.1).		(equals ProtocolVersion.version, see Appendix A.1).
	cipher_spec_length		cipher_spec_length
	This field is the total length of the field cipher_specs. It		This field is the total length of the field cipher_specs. It |
	cannot be zero and must be a multiple of the V2CipherSpec length		cannot be zero and MUST be a multiple of the V2CipherSpec length
	(3).		(3).
	session_id_length		session_id_length
	This field must have a value of zero. |		This field MUST have a value of zero. |
	challenge_length		challenge_length
	The length in bytes of the client's challenge to the server to |		The length in bytes of the client's challenge to the server to |
	authenticate itself. When using the SSLv2 backward compatible |		authenticate itself. When using the SSLv2 backward compatible |
	handshake the client MUST use a 32-byte challenge.		handshake the client MUST use a 32-byte challenge.
	cipher_specs		cipher_specs
	This is a list of all CipherSpecs the client is willing and able		This is a list of all CipherSpecs the client is willing and able |
	to use. There must be at least one CipherSpec acceptable to the		to use. There MUST be at least one CipherSpec acceptable to the
	server.		server.
	session_id		session_id
	This field must be empty. |		This field MUST be empty. |
	challenge		challenge
	The client challenge to the server for the server to identify		The client challenge to the server for the server to identify
	itself is a (nearly) arbitrary length random. The TLS server will		itself is a (nearly) arbitrary length random. The TLS server will
	right justify the challenge data to become the ClientHello.random		right justify the challenge data to become the ClientHello.random
	data (padded with leading zeroes, if necessary), as specified in		data (padded with leading zeroes, if necessary), as specified in
	this protocol specification. If the length of the challenge is		this protocol specification. If the length of the challenge is
	greater than 32 bytes, only the last 32 bytes are used. It is		greater than 32 bytes, only the last 32 bytes are used. It is
	legitimate (but not necessary) for a V3 server to reject a V2		legitimate (but not necessary) for a V3 server to reject a V2
	ClientHello that has fewer than 16 bytes of challenge data.		ClientHello that has fewer than 16 bytes of challenge data.
	Note: Requests to resume a TLS session MUST use a TLS client hello. |		Note: Requests to resume a TLS session MUST use a TLS client hello. |
	E.2. Avoiding man-in-the-middle version rollback		E.2. Avoiding man-in-the-middle version rollback
	When TLS clients fall back to Version 2.0 compatibility mode, they		When TLS clients fall back to Version 2.0 compatibility mode, they |
	should use special PKCS #1 block formatting. This is done so that TLS		SHOULD use special PKCS #1 block formatting. This is done so that TLS
	servers will reject Version 2.0 sessions with TLS-capable clients.		servers will reject Version 2.0 sessions with TLS-capable clients.
	When TLS clients are in Version 2.0 compatibility mode, they set the		When TLS clients are in Version 2.0 compatibility mode, they set the
	right-hand (least-significant) 8 random bytes of the PKCS padding		right-hand (least-significant) 8 random bytes of the PKCS padding
	(not including the terminal null of the padding) for the RSA		(not including the terminal null of the padding) for the RSA
	encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY		encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
	to 0x03 (the other padding bytes are random). After decrypting the		to 0x03 (the other padding bytes are random). After decrypting the |
	ENCRYPTED-KEY-DATA field, servers that support TLS should issue an		ENCRYPTED-KEY-DATA field, servers that support TLS SHOULD issue an
	error if these eight padding bytes are 0x03. Version 2.0 servers		error if these eight padding bytes are 0x03. Version 2.0 servers
	receiving blocks padded in this manner will proceed normally.		receiving blocks padded in this manner will proceed normally.
	F. Security analysis		F. Security analysis
	The TLS protocol is designed to establish a secure connection between		The TLS protocol is designed to establish a secure connection between
	a client and a server communicating over an insecure channel. This		a client and a server communicating over an insecure channel. This
	document makes several traditional assumptions, including that		document makes several traditional assumptions, including that
	attackers have substantial computational resources and cannot obtain		attackers have substantial computational resources and cannot obtain
	secret information from sources outside the protocol. Attackers are		secret information from sources outside the protocol. Attackers are
	skipping to change at page 89, line ? ¶		skipping to change at page 90, line ? ¶
	message, parties thus prove that they know the correct		message, parties thus prove that they know the correct
	pre_master_secret.		pre_master_secret.
	F.1.1.1. Anonymous key exchange		F.1.1.1. Anonymous key exchange
	Completely anonymous sessions can be established using RSA or Diffie-		Completely anonymous sessions can be established using RSA or Diffie-
	Hellman for key exchange. With anonymous RSA, the client encrypts a		Hellman for key exchange. With anonymous RSA, the client encrypts a
	pre_master_secret with the server's uncertified public key extracted		pre_master_secret with the server's uncertified public key extracted
	from the server key exchange message. The result is sent in a client		from the server key exchange message. The result is sent in a client
	key exchange message. Since eavesdroppers do not know the server's		key exchange message. Since eavesdroppers do not know the server's
	private key, it will be infeasible for them to decode the		private key, it will be infeasible for them to decode the |
	pre_master_secret. (Note that no anonymous RSA Cipher Suites are		pre_master_secret. |
	defined in this document).
			Note: No anonymous RSA Cipher Suites are defined in this document.
	With Diffie-Hellman, the server's public parameters are contained in		With Diffie-Hellman, the server's public parameters are contained in
	the server key exchange message and the client's are sent in the		the server key exchange message and the client's are sent in the
	client key exchange message. Eavesdroppers who do not know the		client key exchange message. Eavesdroppers who do not know the
	private values should not be able to find the Diffie-Hellman result		private values should not be able to find the Diffie-Hellman result
	(i.e. the pre_master_secret).		(i.e. the pre_master_secret).
	Warning: Completely anonymous connections only provide protection		Warning: Completely anonymous connections only provide protection
	against passive eavesdropping. Unless an independent tamper-		against passive eavesdropping. Unless an independent tamper-
	proof channel is used to verify that the finished messages		proof channel is used to verify that the finished messages
	were not replaced by an attacker, server authentication is		were not replaced by an attacker, server authentication is
	required in environments where active man-in-the-middle		required in environments where active man-in-the-middle
	attacks are a concern.		attacks are a concern.
	F.1.1.2. RSA key exchange and authentication		F.1.1.2. RSA key exchange and authentication
	With RSA, key exchange and server authentication are combined. The		With RSA, key exchange and server authentication are combined. The
	public key may be either contained in the server's certificate or may		public key may be either contained in the server's certificate or may
	be a temporary RSA key sent in a server key exchange message. When		be a temporary RSA key sent in a server key exchange message. When
	temporary RSA keys are used, they are signed by the server's RSA or		temporary RSA keys are used, they are signed by the server's RSA |
	DSS certificate. The signature includes the current		certificate. The signature includes the current ClientHello.random,
	ClientHello.random, so old signatures and temporary keys cannot be		so old signatures and temporary keys cannot be replayed. Servers may
	replayed. Servers may use a single temporary RSA key for multiple		use a single temporary RSA key for multiple negotiation sessions.
	negotiation sessions.
	Note: The temporary RSA key option is useful if servers need large		Note: The temporary RSA key option is useful if servers need large
	certificates but must comply with government-imposed size limits		certificates but must comply with government-imposed size limits
	on keys used for key exchange.		on keys used for key exchange.
	Note that if ephemeral RSA is not used, compromise of the server's |		Note that if ephemeral RSA is not used, compromise of the server's |
	static RSA key results in a loss of confidentiality for all sessions |		static RSA key results in a loss of confidentiality for all sessions |
	protected under that static key. TLS users desiring Perfect Forward |		protected under that static key. TLS users desiring Perfect Forward |
	Secrecy should use DHE cipher suites. The damage done by exposure of |		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 |		a private key can be limited by changing one's private key (and |
	skipping to change at page 89, line ? ¶		skipping to change at page 90, line ? ¶
	Institute of Standards and Technology, U.S. Department of		Institute of Standards and Technology, U.S. Department of
	Commerce, Work in Progress, May 31, 1994.		Commerce, Work in Progress, May 31, 1994.
	[SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications		[SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications
	Corp., Feb 9, 1995.		Corp., Feb 9, 1995.
	[SSL3] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",		[SSL3] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",
	Netscape Communications Corp., Nov 18, 1996.		Netscape Communications Corp., Nov 18, 1996.
	[REQ] Bradner, S., "Key words for use in RFCs to Indicate |		[REQ] Bradner, S., "Key words for use in RFCs to Indicate |
	Requirement Levels", BCP 14, RFC 2119, March 1997. |		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[TLS1.0] Dierks, T., and Allen, C., "The TLS Protocol, Version 1.0", |		[TLS1.0] Dierks, T., and Allen, C., "The TLS Protocol, Version 1.0", |
	RFC 2246, January 1999. |		RFC 2246, January 1999.
	[X509] CCITT. Recommendation X.509: "The Directory - Authentication |
	Framework". 1988. |		[TLSEXT] Blake-Wilson, S., Nystrom, M, Hopwood, D., Mikkelsen, J., |
			Wright, T., "Transport Layer Security (TLS) Extensions", RFC |
			3546, June 2003.
			[X509] CCITT. Recommendation X.509: "The Directory - Authentication
			Framework". 1988.
	Informative References |		Informative References |
	[AH] Kent, S., and Atkinson, R., "IP Authentication Header", RFC |		[AH] Kent, S., and Atkinson, R., "IP Authentication Header", RFC |
	2402, November 1998. |		2402, November 1998. |
	[BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against |		[BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against |
	Protocols Based on RSA Encryption Standard PKCS #1" in |		Protocols Based on RSA Encryption Standard PKCS #1" in |
	Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages: |		Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages: |
	1--12, 1998. |		1--12, 1998. |
	skipping to change at page 89, line ? ¶		skipping to change at page 90, line ? ¶
	[KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based |		[KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based |
	Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/, |		Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/, |
	March 2003. |		March 2003. |
	[RSADSI] Contact RSA Data Security, Inc., Tel: 415-595-8782 |		[RSADSI] Contact RSA Data Security, Inc., Tel: 415-595-8782 |
	[SCH] B. Schneier. Applied Cryptography: Protocols, Algorithms, |		[SCH] B. Schneier. Applied Cryptography: Protocols, Algorithms, |
	and Source Code in C, Published by John Wiley & Sons, Inc. |		and Source Code in C, Published by John Wiley & Sons, Inc. |
	1994. |		1994. |
	[SEQNUM] Bellovim. S., "Defending Against Sequence Number Attacks", |		[SEQNUM] Bellovim. S., "Defending Against Sequence Number Attacks", |
	RFC 1948, May 1996.		RFC 1948, May 1996. |
	[SUBGROUP] R. Zuccherato, "Methods for Avoiding the Small-Subgroup |		[SUBGROUP] R. Zuccherato, "Methods for Avoiding the Small-Subgroup |
	Attacks on the Diffie-Hellman Key Agreement Method for |		Attacks on the Diffie-Hellman Key Agreement Method for |
	S/MIME", RFC 2785, March 2000.		S/MIME", RFC 2785, March 2000. |
	[TCP] Postel, J., "Transmission Control Protocol," STD 7, RFC 793, |		[TCP] Postel, J., "Transmission Control Protocol," STD 7, RFC 793, |
	September 1981.		September 1981. |
	[TIMING] Boneh, D., Brumley, D., "Remote timing attacks are |		[TIMING] Boneh, D., Brumley, D., "Remote timing attacks are |
	practical", USENIX Security Symposium 2003.		practical", USENIX Security Symposium 2003. |
	[XDR] R. Srinivansan, Sun Microsystems, RFC-1832: XDR: External		[XDR] R. Srinivansan, Sun Microsystems, RFC-1832: XDR: External
	Data Representation Standard, August 1995.		Data Representation Standard, August 1995.
	Credits |		Credits |
	Working Group Chair |		Working Group Chair |
	Win Treese		Win Treese
	EMail: treese@acm.org |		EMail: treese@acm.org |
End of changes. 47 change blocks.
	81 lines changed or deleted		116 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/