RFC Errata
Found 4 records.
Status: Verified (2)
RFC 4346, "The Transport Layer Security (TLS) Protocol Version 1.1", April 2006
Note: This RFC has been obsoleted by RFC 5246
Note: This RFC has been updated by RFC 4366, RFC 4680, RFC 4681, RFC 5746, RFC 6176, RFC 7465, RFC 7507, RFC 7919
Source of RFC: tls (sec)
Errata ID: 1075
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eric Rescorla
Date Reported: 2006-02-26
Section 4.7 says:
PKCS #1 block type 0 or type 1, as described in [PKCS1A].
It should say:
PKCS #1 block type 1, as described in [PKCS1A].
Errata ID: 1896
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-05-29
Verifier Name: Pasi Eronen
Date Verified: 2009-10-14
Section 7.2.2 says:
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.
Note: Differentiating between bad_record_mac and decryption_failed
alerts may permit certain attacks against CBC mode as used in
TLS [CBCATT]. It is preferable to uniformly use the
bad_record_mac alert to hide the specific type of the error.
It should say:
decryption_failed
This alert was used in TLS version 1.0, and MUST NOT be sent in
TLS 1.1.
Note: Differentiating between bad_record_mac and decryption_failed
alerts may have permitted certain attacks against CBC mode
as used in TLS 1.0 [CBCATT]. It is preferable to uniformly
use the bad_record_mac alert to hide the specific type of
the error.
Notes:
(split off from Errata ID 117 )
The original text contradicted the text for bad_record_mac
("This alert also MUST be returned if an alert is sent because
a TLSCiphertext decrypted in an invalid way").
Status: Held for Document Update (2)
RFC 4346, "The Transport Layer Security (TLS) Protocol Version 1.1", April 2006
Note: This RFC has been obsoleted by RFC 5246
Note: This RFC has been updated by RFC 4366, RFC 4680, RFC 4681, RFC 5746, RFC 6176, RFC 7465, RFC 7507, RFC 7919
Source of RFC: tls (sec)Errata ID: 116
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: David Hopwood
Date Reported: 2006-05-11
Held for Document Update by: Pasi Eronen
Report Text:
Following references should all be to Section 12: Section 6: # See Section 11 for IANA Considerations for ContentType values. Section 7.2.2: # See Section 11 for IANA Considerations for alert values. Section 7.4: # See Section 11 for IANA Considerations for these values. Section 7.4.4: # Additional information describing the role of IANA in the allocation # of ClientCertificateType code points is described in Section 11. from pending
Errata ID: 117
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-05-29
Held for Document Update by: Pasi Eronen
Date Held: 2009-09-25
(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.
Notes:
(Item C1 split to separate Errata ID 1896)
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.
from pending