RFC 4366, "Transport Layer Security (TLS) Extensions", April 2006

Note: This RFC has been obsoleted by RFC 5246, RFC 6066

Note: This RFC has been updated by RFC 5746

Errata ID: 111
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-05-29
Rejected by: David Hopwood
Date Rejected: 2006-05-29

(1)  imprecise syntax description for `ciphersuites`

This is an issue inherited from RFC 2246, RFC 3546, and RFC 4346;
I already have reported this issue against RFC 4346 (and RFC 4347
as well).

Section 7.4.1.2 of RFC 4346, on page 37 of RFC 4346 defines the syntax:

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

According to the specifications given in Section 4.3 of RFC 4346,
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 2.1 of RFC 4366 (on page 5),
an extended version of the basic declaration in Section 7.4.1.2
of RFC 4346 (on top of page 38), stating

         struct {
             ProtocolVersion client_version;
             Random random;
             SessionID session_id;
             CipherSuite cipher_suites<2..2^16-1>;
             CompressionMethod compression_methods<1..2^8-1>;
             Extension client_hello_extension_list<0..2^16-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>;
             Extension client_hello_extension_list<0..2^16-1>;
         } ClientHello;


(2)  incomplete semantics specified for "server_name" extension

Section 3.1 of RFC 4366, on page 9, defines the "server_name"
extension as containing a *list* of `ServerName` structures.

On page 10, the same section says:

   It is RECOMMENDED that clients include an extension of type
   "server_name" in the client hello whenever they locate a server by a
   supported name type.

   A server that receives a client hello containing the "server_name"
   extension MAY use the information contained in the extension to guide
   its selection of an appropriate certificate to return to the client,
   and/or other aspects of security policy.  In this event, the server
   SHALL include an extension of type "server_name" in the (extended)
   server hello.  The "extension_data" field of this extension SHALL be
   empty.

   If the server understood the client hello extension but does not
|  recognize the server name, it SHOULD send an "unrecognized_name"
             ^^^
   alert (which MAY be fatal).

and on page 19, Section 4 defines the error alert,

   -  "unrecognized_name": this alert is sent by servers that receive a
|     server_name extension request, but do not recognize the server
      name.  This message MAY be fatal.                   ^^^

All these clauses apparently state the semantics for the "server_name"
extension solely in the case where the data field of the extension in
the (extended) Client Hello contains a *single* `ServerName` structure.

IMHO, if the client, as allowed by the syntax, indeed specifies
multiple names in the "server_name" extension -- a feature that
seems to be useful in certain scenarios --, it needs to get feedback
from the server as to which of the specified names has been used for
the purpose described in the second paragraph cited above.
Hence, the server should better be instructed by the specification
to include the selected name in the "server_name" extension returned
to the client in the (extended) Server Hello.
For backwards compatibility, the specification should perhaps
prescribe to omit this feedback, reverting to the specification
cited above) in the case that the Client Hello received contained
only a single server name.

In parallel, the semantics of the "unrecognized_name" alerts should
be amended to mean: all received names are unrecognized.


(3)  incomplete / outdated referencing text

The paragraph of Section 3.2 spanning from page 11 to page 12, says:

                               [...].  For example, if the negotiated
<page break>
   length is 2^9=512, then for currently defined cipher suites (those
   defined in [TLS], [KERB], and [AESSUITES]), and when null compression
   is used, the record layer output can be at most 793 bytes: 5 bytes of
   headers, 512 bytes of application data, 256 bytes of padding, and 20
   bytes of MAC.  [...]

This apparently is not up to date.  I propose to either substitute
"[TLSbis]," for "[TLS]," in the text above -- thus referring only to
current specifications --, or even to substitute "[TLS] and [TLSbis],"
for "[TLS]," there -- thus honoring to the predecessor.


(4)   spurious blank line

Within Section 3.6, the 5th paragraph on page 18 is interrupted
by a blank line in the middle of a sentence.
Perhaps this is a formatting artifact inherited from the page break
that was at this place in the text in RFC 3546.

Thus, the text body:

   Servers return a certificate response along with their certificate by
   sending a "CertificateStatus" message immediately after the
   "Certificate" message (and before any "ServerKeyExchange" or
   "CertificateRequest" messages).  If a server returns a
|
   "CertificateStatus" message, then the server MUST have included an
   extension of type "status_request" with empty "extension_data" in the
   extended server hello.

should be joined to say:

   Servers return a certificate response along with their certificate by
   sending a "CertificateStatus" message immediately after the
   "Certificate" message (and before any "ServerKeyExchange" or
   "CertificateRequest" messages).  If a server returns a
   "CertificateStatus" message, then the server MUST have included an
   extension of type "status_request" with empty "extension_data" in the
   extended server hello.


(5)  punctuation issue in Informative Reference

The following Informative Reference entry on page 28 contains
syntactically inconsistent punctuation:

   [MAILINGLIST]  J. Mikkelsen, R. Eberhard, and J. Kistler, "General
                  ClientHello extension mechanism and virtual hosting,"
                  ietf-tls mailing list posting, August 14, 2000.

should say:

   [MAILINGLIST]  J. Mikkelsen, R. Eberhard, and J. Kistler, "General
|                 ClientHello extension mechanism and virtual hosting",
                  ietf-tls mailing list posting, August 14, 2000.

Notes:

All excerpts from the RFC text are taken literally, 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.

Issue (2) above certainly needs discussion; perhaps you know what
once was intended. The other issues seem to be straightforward.

from pending

Report New Errata