Draft: draft-ietf-tls-tls13

Commentary: Per WG consensus , remove static RSA .
Paragraph (version A):
draft-01 - Removed support for compression.
Paragraph (version B):
draft-01 - Removed support for compression.  - Removed support for
static RSA key exchange.
Paragraph (version A):
In public key encryption, a public key algorithm is used to encrypt
data in such a way that it can be decrypted only with the matching
private key.  A public-key-encrypted element is encoded as an opaque
vector <0..2^16-1>, where the length is specified by the encryption
algorithm and key.
Paragraph (version A):
RSA encryption is done using the RSAES-PKCS1-v1_5 encryption scheme
defined in RFC3447.
Paragraph (version A):
level of security: if you negotiate 3DES with a 1024-bit RSA key
exchange with a host whose certificate you have verified, you can
expect to be that secure.
Paragraph (version B):
level of security: if you negotiate AES with a 1024-bit DHE key
exchange with a host whose certificate you have verified, you can
expect to be that secure.
Paragraph (version A):
If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had
sent the value {sha1,rsa}.
Paragraph (version B):
If the negotiated key exchange algorithm is one of (DHE_RSA,
DH_RSA, ECDH_RSA, ECDHE_RSA), behave as if client had sent the
value {sha1,rsa}.
Paragraph (version A):
With this message, the premaster secret is set, either by direct
transmission of the RSA-encrypted secret or by the transmission of
Diffie-Hellman parameters that will allow each side to agree upon
the same premaster secret.
Paragraph (version B):
This message contains the client's Diffie-Hellman parameters that
will allow each side to agree upon the same premaster secret.
Paragraph (version A):
If RSA is being used for key agreement and authentication, the
client generates a 48-byte premaster secret, encrypts it using the
public key from the server's certificate, and sends the result in
an encrypted premaster secret message.  This structure is a
variant of the ClientKeyExchange message and is not a message in
itself.
Paragraph (version A):
Note: The version number in the PreMasterSecret is the version
offered by the client in the ClientHello.client_version, not the
version negotiated for the connection.  This feature is designed to
prevent rollback attacks.  Unfortunately, some old implementations
use the negotiated version instead, and therefore checking the
version number may lead to failure to interoperate with such
incorrect client implementations.
Paragraph (version A):
Client implementations MUST always send the correct version number in
PreMasterSecret.  If ClientHello.client_version is TLS 1.1 or higher,
server implementations MUST check the version number as described in
the note below.  If the version number is TLS 1.0 or earlier, server
implementations SHOULD check the version number, but MAY have a
configuration option to disable the check.  Note that if the check
fails, the PreMasterSecret SHOULD be randomized as described below.
Paragraph (version A):
Note: Attacks discovered by Bleichenbacher BLEI and Klima et al.
KPR03 can be used to attack a TLS server that reveals whether a
particular message, when decrypted, is properly PKCS#1 formatted,
contains a valid PreMasterSecret structure, or has the correct
version number.
Paragraph (version A):
Note that explicitly constructing the pre_master_secret with the
ClientHello.client_version produces an invalid master_secret if the
client has sent the wrong version in the original pre_master_secret.
Paragraph (version A):
Although no practical attacks against this construction are known,
Klima et al.  KPR03 describe some theoretical attacks, and therefore
the first construction described is RECOMMENDED.
Paragraph (version A):
The RSAES-OAEP encryption scheme defined in RFC3447 is more secure
against the Bleichenbacher attack.  However, for maximal
compatibility with earlier versions of TLS, this specification uses
the RSAES-PKCS1-v1_5 scheme.  No variants of the Bleichenbacher
attack are known to exist provided that the above recommendations are
followed.
Paragraph (version A):
Implementation note: Public-key-encrypted data is represented as an
opaque vector <0..2^16-1> (see cryptographic-attributes).  Thus, the
RSA-encrypted PreMasterSecret in a ClientKeyExchange is preceded by
two length bytes.  These bytes are redundant in the case of RSA
because the EncryptedPreMasterSecret is the only data in the
ClientKeyExchange and its length can therefore be unambiguously
determined.  The SSLv3 specification was not clear about the encoding
of public-key- encrypted data, and therefore many SSLv3
implementations do not include the length bytes -- they encode the
RSA-encrypted data directly in the ClientKeyExchange message.
Paragraph (version A):
This specification requires correct encoding of the
EncryptedPreMasterSecret complete with length bytes.  The resulting
PDU is incompatible with many SSLv3 implementations.  Implementors
upgrading from SSLv3 MUST modify their implementations to generate
and accept the correct encoding.  Implementors who wish to be
compatible with both SSLv3 and TLS should make their implementation's
behavior dependent on the protocol version.
Paragraph (version A):
Implementation note: It is now known that remote timing-based attacks
on TLS are possible, at least when the client and server are on the
same LAN.  Accordingly, implementations that use static RSA keys MUST
use RSA blinding or some other anti-timing technique, as described in
TIMING.
Paragraph (version A):
When RSA is used for server authentication and key exchange, a 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
private key to decrypt the pre_master_secret.  Both parties then
convert the pre_master_secret into the master_secret, as specified
above.
Paragraph (version A):
In the absence of an application profile standard specifying
otherwise, a TLS-compliant application MUST implement the cipher
suite TLS_RSA_WITH_AES_128_CBC_SHA (see the-cipher-suite for the
definition).
Paragraph (version B):
In the absence of an application profile standard specifying
otherwise, a TLS-compliant application MUST implement the cipher
suite TODO:Needs to be selected [1].  (See the-cipher-suite for the
definition).