Transport Layer Security Working Group                      Tim Dierks
INTERNET-DRAFT                                   Consensus Development
Expires May 31, 1997                                 November 26, 1996


            Modifications to the SSL protocol for TLS
                 <draft-ietf-tls-ssl-mods-00.txt>



Status of this memo

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet- Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or made obsolete by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as work in progress.

To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).


Abstract

This document recommends for several modifications be made to the SSL
3.0 protocol as it is standardized by the IETF under the name of TLS.
These changes primarily standardize various technical details of the
protocol and make some other minor modifications.

. MAC algorithm

SSL 3.0 uses a version of the HMAC algorithm which is not the most
recent or the recommended standard. The SSL MAC is defined as:

    hash(MAC_secret + pad_2 +
         hash(MAC_secret + pad_1 + data));

Where data is the concatenation of several record header fields and the
record data. pad_1 and pad_2 are repetitions of the value 0x36 and 0x5C,
respectively. These bytes are repeated a number of times dependent on
which hash algorithm is being used: 48 times for MD5 and 40 times for
SHA.

I recommend moving to HMAC as described in
<draft-ietf-ipsec-hmac-md5-01.txt> by incorporating this algorithm into
the TLS standard (or by referring to it, should it become an RFC
standard). This formulation uses a 64 byte pad which is combined with
the MAC secret using XOR rather than concatenation.

Dierks, T.                     Expires May, 1997               [Page 1]

INTERNET-DRAFT                   SSL-TLS mods             November 1996

This would replace the MAC formulations used in the certificate verify
and finished messages (where the MAC_secret is the master secret) and
the MAC formulation used in the record layer (where the MAC_secret is
generated specifically for each connection direction.)

. MAC contents

Currently, the SSL record layer applies the MAC to every element in the
record except for the protocol version encoded into every packet. It is
inappropriate to transmit values which might affect the functionality of
the connection without applying the MAC to these values. If the version
number does not control the function of the channel, it should be
eliminated; if it does affect the communication, it should be MACed.
Thus, I recommend that the data which is MAC`d be amended to:

    seq_num + SSLCompressed.type + SSLCompressed.version +
        SSLCompressed.length + SSLCompressed.fragment

. Block padding

Padding is required when working with block ciphers to expand source
data to an even multiple of the block length. SSL specifies padding, but
does not specify a particular value. In order to ensure that
implementors do not accidentally transmit unintended data in
uninitialized padding fields, I recommend that the TLS add a requirement
that the padding be initialized to a particular value. I propose that
the padding field must be zeroed and that implementations should check
for appropriate padding on incoming records.

. Message order standardization

In the original SSL 3.0 specification, an error made the statement of
when the certificate request message should be transmitted unclear, and
different implementations send it in two places: either before or after
the server key exchange message. I propose that for the TLS
specification, the certificate request message be clearly specified to
follow the server key exchange message.

. Certificate chain contents

In the original SSL 3.0 specification, the text required that a complete
X.509 certificate chain be sent up to and including the self-signed root
cert. It is claimed that this was not the intent of the drafters, and in
fact, many implementations do not comply with this portion of the
standard. Thus, I propose that the TLS specification clearly state that
a partial certificate chain is acceptable if it can be reasonably hoped
that the peer will hold all needed certificates to complete the chain.






Dierks, T.                     Expires May, 1997               [Page 2]

INTERNET-DRAFT                   SSL-TLS mods             November 1996

. The no_certificate alert

The no_certificate alert, which is to be sent by a client which does not
have a suitable certificate to provide a server, presents a subtle
problem to the SSL implementer. Because the message order of the SSL
protocol is for the most part well defined and enforced, what messages
have arrived is very important to the state machine which manages the
handshake protocol. Because this alert can replace a handshake message,
the alert protocol must communicate to the handshake protocol that this
alert has arrived. This is the only place where such a piece of
promiscuity is required, thus I recommend that in place of sending a
no_certificate alert, TLS clients who do not have a suitable certificate
for a server submit instead an Certificate message which contains no
certificates.

. Additional alerts

SSL doesn`t have a great deal of variety in its error alerts. I propose
that the following alerts be added to the specification:

    internal_error [fatal]: an internal error unrelated to the peer or
the correctness of the protocol makes it impossible to continue (such as
a memory allocation failure).
    user_canceled [fatal]: the user aborted this handshake or connection
for some reason.
    decrypt_error [fatal]: a public or private key operation failed due
to using the wrong key
    decode_error [fatal]: a message could not be decoded because some
field was out of the specified range or the length of the message was
incorrect.
    export_restriction [fatal]: an attempt to circumvent export
restrictions was detected; for example, attemption to transfer a 1024
bit ephemeral RSA key for the RSA_EXPORT handshake method.
    protocol_version [fatal]: the protocol version the peer has
attempted to negotiate is recognized, but not supported. (For example,
old protocol versions might be avoided for security reasons).
    record_overflow [fatal]: an SSLCiphertext record was received which
had a length more than 2^14+2048 bytes, or a record decrypted to a
SSLCompressed record with more than 2^14+1024 bytes.
    decryption_failed [fatal]: a SSLCiphertext decrypted in an invalid
way: either it wasn`t an even multiple of the block length or its
padding values, when checked, weren`t correct.
    access_denied [fatal]: a valid certificate was received, but it did
not pass the access control mechanism.
    unknown_ca [fatal]: a valid certificate chain or partial chain was
received, but the certificate was not accepted because the CA
certificate could not be located or couldn`t be matched with a known,
trusted CA.
    insufficient_security [fatal]: returned instead of handshake_failure
when a negotiation has failed specifically because one of the parties
requires ciphers more secure than those supported by their peer.
    no_renegotiation [warning]: generated in response to a hello request

Dierks, T.                     Expires May, 1997               [Page 3]

INTERNET-DRAFT                   SSL-TLS mods             November 1996

or a client hello sent on an already negotiated channel. This informs
the requestor that no response will be generated, as this entity does
not want to renegotiate security parameters (as you might wish to do if
there` no way to communicate security parameters up the stack to the
client after initial negotiation.

. Seperation of Record and Handshake layers

The SSL Record Protocol and Handshake Protocol can be viewed as two
independant layered protocols: the Record Protocol provides encrypted,
reliable transport, and the Handshake Protocol provides algorithm and
key negotiation and peer authentication. I propose that they be formally
seperated into two documents, or at least two distinct sections of the
TLS document. This should make their interoperation clearer, aiding
security analysis and perhaps allowing utilization of the Record
Protocol with some other handshake protocol or vice-versa.

. Additional Record Protocol clients

The SSL Record Protocol supports transmitting many different kinds of
records over a single connection. This is already used for
distinguishing different kinds of protocol messages from each other and
from application data. I propose that TLS clearly specify that layered
protocols are allowed to use the Record Protocol to transport new record
types.




























Dierks, T.                     Expires May, 1997               [Page 4]