Subject: RFC 4346 (TLS 1.1) errata and other issues

From: Alfred Hönes <[email-masked]>
Date: Mon, 29 May 2006 11:14:31 +0200 (MESZ)

Hello,

studying the recently published RFC 4346 authored/edited by you
I found a couple of issues I'd like to report.
(Some of these issues in fact are legacy issues from RFC 2246.)

All excerpts from the RFC text are taken keeping their original
formatting, and modified text is formatted in conformance with
RFC guidelines again.

I use change bars ('|' in column 1) and casual up/down pointing
tags ('^^^' / 'vvv' marks in extra lines) to emphasize the location
of textual issues and/or proposed textual enhancements/corrections.

Content issues
==============

(C1)  inconsistent specification of requirements

Section 7.2.2 of RFC 4346, on page 28 says:

   bad_record_mac
      This alert is returned if a record is received with an incorrect
      MAC.  This alert also MUST be returned if an alert is sent because
      a TLSCiphertext 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.  This message is always fatal.

and then continues:

   decryption_failed
      This alert MAY be returned if a TLSCiphertext 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.
      This message is always fatal.

The "MUST" in the former paragraph turns the second paragraph void
because the precondition clauses are identical.  I strongly suspect
that it was intended to specify a "SHOULD" requirement in the first
clause, with the 'fallback' "MAY" clause in the second paragraph.
Therefore, the first clause above should probably say:

   bad_record_mac
      This alert is returned if a record is received with an incorrect
      MAC.
|     This alert also SHOULD be returned if an alert is sent because
      a TLSCiphertext 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.  This message is always fatal.

[I have inserted an additional line break after the first sentence,
 both to clearly separate the two usage cases, and to keep the line
 formatting of the subsequent lines unchanged.]

(C2)  imprecise data description for `ciphersuites`

Section 7.4.1.2, on page 37 defines the syntax:

      uint8 CipherSuite[2];    /* Cryptographic suite selector */

According to the specifications given in Section 4.3, vectors
of type CipherSuite strictly must have byte lengths being a
multiple of 2.
This also means that the upper bound for a varaiable-length array
of type CipherSuite should always be a multiple of 2.
Hence, the declaration in Section 7.4.1.2, on top of page 38,

      struct {
          ProtocolVersion client_version;
          Random random;
          SessionID session_id;
          CipherSuite cipher_suites<2..2^16-1>;
          CompressionMethod compression_methods<1..2^8-1>;
      } ClientHello;

should better say:

      struct {
          ProtocolVersion client_version;
          Random random;
          SessionID session_id;
|         CipherSuite cipher_suites<2..2^16-2>;
          CompressionMethod compression_methods<1..2^8-1>;
      } ClientHello;

This issue recurs in Appendix A.4.1 (2nd line from bottom of p.57)
and at various places in other TLS RFCs, in particular in RFC 4347
and RFC 4366 -- see my errata messages for these RFCs.

Historical Note:
  In SSL 2.0, the CipherSuite construct was 3 bytes long.
  Because 3 divides 2^16-1,  <3..2^16-1>  was an appropriate size
  range then.  The issue has been introduced with SSL 3.0.

(C3)  missing Reference

Appendix B, at the bottom of page 66, contains the Glossary item:

   RC2
      A block cipher developed by Ron Rivest at RSA Data Security, Inc.
      [RSADSI] described in [RC2].

There is no such Reference "[RSADSI]" in the Informative References
Section, on pp. 82 ff. -- apparently, it has been prematurely deleted
from RFC 2246.  Perhaps, nothing would be lost when replacing the
above Glossary item by:

   RC2
      A block cipher developed by Ron Rivest described in [RC2].

(C4)  Outdated Normative Reference

RFC 4346 has been jointly published with RFC 4366, which has
obsoleted RFC 3546.
Therefore, it would have been much more consistent to replace,
in the Normative References Section, on page 82, the entry:

   [TLSEXT]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 3546, June 2003.

by:

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

(C5)  unexpected / inappropriate Reference

Page 83 contains the inappropriate Informative Reference:

   [TCP]      Hellstrom, G. and P. Jones, "RTP Payload for Text
              Conversation", RFC 4103, June 2005.

This clearly should be:

|  [TCP]      Postel, J., "Transmission Control Protocol", STD 7,
|             RFC 793, September 1981.

(Cf. the single citation to [TCP], in the first paragraph of Section 1,
on page 4.)

Simple textual issues (errata)
==============================

(E1)  typo

The second paragraph of Section 3 of RFC 4346, on page 6, says:

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

It should perhaps say:

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

(E2)  copy-and-paste error (?)

At the bottom of page 11, Section 4.7 of RFC 4346 says:

   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 signing
   algorithm and key.

It should say:

   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 encrypting
   algorithm and key.
                                                            ^^^^^^^^^^

(E3)  typo

The beginning of the first paragraph of Section 6.1, on page 15,

   A TLS connection state is the operating environment of the TLS Record
   Protocol.  It specifies a compression algorithm, and encryption
   algorithm, and a MAC algorithm.  In addition, the parameters for

should say (replacing "and" by "an"):

   A TLS connection state is the operating environment of the TLS Record
|  Protocol.  It specifies a compression algorithm, an encryption
   algorithm, and a MAC algorithm.  In addition, the parameters for

(E4)  word twister

Near the bottom of page 15, Section 6.1 says:

   compression algorithm
      An algorithm to be used for data compression.  This specification
      must include all information the algorithm requires compression.

It should perhaps say:

   compression algorithm
      An algorithm to be used for data compression.  This specification
|     must include all information the compression algorithm requires.

(E5)  improper indentation

In Section 7.4.1.1, on page 36, a headline is indented too much;
the text,

         Structure of this message:

             struct { } HelloRequest;

   Note: This message MUST NOT be included ...

should say:

|  Structure of this message:

             struct { } HelloRequest;

   Note: This message MUST NOT be included ...

(E6)  improper line (un)folding and irregular indentation

In Section 7.4.1.2, at the bottom of page 36, the text,

      struct {
         uint32 gmt_unix_time;
         opaque random_bytes[28];
      } Random;

   gmt_unix_time The current time and date in standard UNIX 32-bit
      format (seconds since the midnight starting Jan 1, 1970, GMT,
      ignoring leap seconds) according to the sender's internal clock.
      Clocks are not required to be set correctly by the basic TLS
      Protocol; higher-level or application protocols may define
      additional requirements.

         random_bytes
             28 bytes generated by a secure random number generator.

following the layout style followed in the remainder of the document
should be formatted as:

      struct {
         uint32 gmt_unix_time;
         opaque random_bytes[28];
      } Random;

|  gmt_unix_time
|     The current time and date in standard UNIX 32-bit
      format (seconds since the midnight starting Jan 1, 1970, GMT,
      ignoring leap seconds) according to the sender's internal clock.
      Clocks are not required to be set correctly by the basic TLS
      Protocol; higher-level or application protocols may define
      additional requirements.

|  random_bytes
|     28 bytes generated by a secure random number generator.

(E7)  improper line (un)folding

The last paragraph of Section 7.4.1.3, on page 40,

   compression_method The single compression algorithm selected by the
      server from the list in ClientHello.compression_methods.  For
      resumed sessions this field is the value from the resumed session
      state.

consistently should be formatted as:

|  compression_method
|     The single compression algorithm selected by the server from the
      list in ClientHello.compression_methods.  For resumed sessions
      this field is the value from the resumed session state.

(E8)  improper line (un)folding and irregular indentation

In Section 7.4.7.1, on page 48, the clauses,

      client_version The latest (newest) version supported by the
         client.  This is used to detect version roll-back attacks.
         Upon receiving the premaster secret, the server SHOULD check
         that this value matches the value transmitted by the client in
         the client hello message.

      random
          46 securely-generated random bytes.

consistently should be formatted as:

|     client_version
|        The latest (newest) version supported by the client.  This is
         used to detect version roll-back attacks.  Upon receiving the
         premaster secret, the server SHOULD check that this value
         matches the value transmitted by the client in the client hello
         message.

      random
|        46 securely-generated random bytes.

and subsequently, the clause,

      pre_master_secret
          This random value is generated by the client and is used to
          generate the master secret, as specified in Section 8.1.

should be:

      pre_master_secret
|        This random value is generated by the client and is used to
|        generate the master secret, as specified in Section 8.1.

(E9)  spurious text line

During the removal of the "EXPORT" ciper suites from Appendix C,
a text line from RFC 2246 has been left there inadvertently.
The table, at the bottom of page 68,

      Key
      Exchange
      Algorithm     Description                        Key size limit

      DHE_DSS       Ephemeral DH with DSS signatures   None
      DHE_RSA       Ephemeral DH with RSA signatures   None
      DH_anon       Anonymous DH, no signatures        None
      DH_DSS        DH with DSS-based certificates     None
      DH_RSA        DH with RSA-based certificates     None
|                                                      RSA = none
      NULL          No key exchange                    N/A
      RSA           RSA key exchange                   None

should say:

      Key
      Exchange
      Algorithm     Description                        Key size limit

      DHE_DSS       Ephemeral DH with DSS signatures   None
      DHE_RSA       Ephemeral DH with RSA signatures   None
      DH_anon       Anonymous DH, no signatures        None
      DH_DSS        DH with DSS-based certificates     None
      DH_RSA        DH with RSA-based certificates     None
      NULL          No key exchange                    N/A
      RSA           RSA key exchange                   None

(E10) improper language

During the addition of the third protocol variant, text in Appendix E
has become improper, stiil talking about "both" versions.

The second paragraph of Appendix E, on page 71,

   TLS versions 1.1 and 1.0, and SSL 3.0 are very similar; thus,
   supporting both is easy.  TLS clients who wish [...]
              ^^^^
should say, e.g.:

   TLS versions 1.1 and 1.0, and SSL 3.0 are very similar; thus,
|  supporting all is easy.  TLS clients who wish [...]
              ^^^

(E11) improper line (un)folding

Appendix E.1, near the bottom on page 73, contains the clause:

   challenge The client challenge to the server for the server to
      identify itself is a (nearly) arbitrary-length random.  The TLS
      server will right-justify the challenge data to become the
      ClientHello.random data (padded with leading zeroes, if
      necessary), as specified in this protocol specification.  If the
      length of the challenge 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 ClientHello that has fewer than 16 bytes of
      challenge data.

This should be formatted as:

|  challenge
|     The client challenge to the server for the server to identify
      itself is a (nearly) arbitrary-length random.  The TLS server will
      right-justify the challenge data to become the ClientHello.random
      data (padded with leading zeroes, if necessary), as specified in
      this protocol specification.  If the length of the challenge 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
      ClientHello that has fewer than 16 bytes of challenge data.

(E12) punctuation issues in References

The following Normative Reference entries on page 81/82 contain
syntactically inconsistent punctuation.

   [AES]      National Institute of Standards and Technology,
              "Specification for the Advanced Encryption Standard (AES)"
              FIPS 197.  November 26, 2001.
should say:
   [AES]      National Institute of Standards and Technology,
              "Specification for the Advanced Encryption Standard
|             (AES)", FIPS 197.  November 26, 2001.
                    ^

   [3DES]     W. Tuchman, "Hellman Presents No Shortcut Solutions To
              DES," IEEE Spectrum, v. 16, n. 7, July 1979, pp. 40-41.
should say:
   [3DES]     W. Tuchman, "Hellman Presents No Shortcut Solutions To
|             DES", IEEE Spectrum, v. 16, n. 7, July 1979, pp. 40-41.
                 ^^

   [DES]      ANSI X3.106, "American National Standard for Information
              Systems-Data Link Encryption," American National Standards
              Institute, 1983.
should say:
   [DES]      ANSI X3.106, "American National Standard for Information
|             Systems-Data Link Encryption", American National Standards
              Institute, 1983.
                                          ^^

   [DSS]      NIST FIPS PUB 186-2, "Digital Signature Standard,"
              National Institute of Standards and Technology, U.S.
              Department of Commerce, 2000.
should say:                                                   vv
|  [DSS]      NIST FIPS PUB 186-2, "Digital Signature Standard",
              National Institute of Standards and Technology, U.S.
              Department of Commerce, 2000.

   [SHA]      NIST FIPS PUB 180-2, "Secure Hash Standard," National
              Institute of Standards and Technology, U.S. Department of
              Commerce., August 2001.
should say:                                             vv
|  [SHA]      NIST FIPS PUB 180-2, "Secure Hash Standard", National
              Institute of Standards and Technology, U.S. Department of
              Commerce., August 2001.

Similarly, the following Informative Reference entry on page 83,

   [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.

should say:

   [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.

(E13) mis-spelled author name in Informative Reference

The name of Alan O. Freier has been mis-spelled on page 83, in the
Informative Reference,

   [SSL3]     A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0
              Protocol", Netscape Communications Corp., Nov 18, 1996.

which should say:
                   vv
|  [SSL3]     A. Freier, P. Karlton, and P. Kocher, "The SSL 3.0
              Protocol", Netscape Communications Corp., Nov 18, 1996.

I propose to post an Errata Note covering the above issues,
to the RFC Editor's RFC Errata web page.

I consider only issue (C1) substantive, because it corrects
the requirements language, and thus requires consensus;
all other issues seem to be straightforward.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+