RFC Errata
Found 9 records.
Status: Reported (9)
RFC 6347, "Datagram Transport Layer Security Version 1.2", January 2012
Note: This RFC has been obsoleted by RFC 9147
Note: This RFC has been updated by RFC 7507, RFC 7905, RFC 8996, RFC 9146
Source of RFC: tls (sec)
Errata ID: 3917
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2014-03-14
Section 4.2.1 says:
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
opaque cookie<0..2^8-1>; // New field
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
} ClientHello;
It should say:
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
opaque cookie<0..2^8-1>; // New field
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
select (extensions_present) {
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ClientHello;
Notes:
This also affects Section 4.3.2 where the same structure is repeated.
Extensions are a part of TLS. They are also part of DTLS in practice, but the RFC omits them. The corrected text includes the relevant part of the ClientHello from RFC 5246.
Errata ID: 4103
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Manuel Pégourié-Gonnard
Date Reported: 2014-09-08
Section 4.2.1 says:
[p. 15] DTLS 1.2 server implementations SHOULD use DTLS version 1.0 regardless of the version of TLS that is expected to be negotiated. [p. 16] The server MUST use the same version number in the HelloVerifyRequest that it would use when sending a ServerHello. [p. 15] DTLS 1.2 and 1.0 clients MUST use the version solely to indicate packet formatting (which is the same in both DTLS 1.2 and 1.0) and not as part of version negotiation. In particular, DTLS 1.2 clients MUST NOT assume that because the server uses version 1.0 in the HelloVerifyRequest that the server is not DTLS 1.2 or that it will eventually negotiate DTLS 1.0 rather than DTLS 1.2. [p. 16] Upon receipt of the ServerHello, the client MUST verify that the server version values match.
It should say:
[p. 15] DTLS 1.2 server implementations MAY use DTLS version 1.0 regardless of the version of TLS that is expected to be negotiated, or the version that is expected to be negotiated. [p. 15] DTLS 1.2 and 1.0 clients MUST use the version solely to indicate packet formatting (which is the same in both DTLS 1.2 and 1.0) and not as part of version negotiation. In particular, DTLS 1.2 clients MUST NOT assume that because the server uses version 1.0 in the HelloVerifyRequest that the server is not DTLS 1.2 or that it will eventually negotiate DTLS 1.0 rather than DTLS 1.2. [p. 16] [Delete text relating to HelloVerifyRequest.server_version]
Notes:
The statements on the bottom of page 15 and on the top of page 16 are mutually contradictory. It looks like the statements on page 16 were copied from RFC 4347, but the intention was to replace them with the version from page 15 in this revision of the standard.
Errata ID: 5186
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Chen Wumao
Date Reported: 2017-11-28
Section 4.2.4 says:
[p17] In order to avoid sequence number duplication in case of multiple HelloVerifyRequests, the server MUST use the record sequence number in the ClientHello as the record sequence number in the HelloVerifyRequest. [p17] In order to avoid sequence number duplication in case of multiple cookie exchanges, the server MUST use the record sequence number in the ClientHello as the record sequence number in its initial ServerHello.
It should say:
[p17] In order to avoid sequence number duplication in case of multiple HelloVerifyRequests, the server MUST use the message_seq in the ClientHello as the message_seq in the HelloVerifyRequest. [p17] In order to avoid sequence number duplication in case of multiple cookie exchanges, the server MUST use the message_seq in the ClientHello as the message_seq in its initial ServerHello.
Notes:
the "record sequence number" here should be message_seq.
Errata ID: 4104
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Manuel Pégourié-Gonnard
Date Reported: 2014-09-08
Section 4.1 says:
[Page 8] In order to ensure that any given sequence/epoch pair is unique, implementations MUST NOT allow the same epoch value to be reused within two times the TCP maximum segment lifetime. In practice, TLS implementations rarely rehandshake; therefore, we do not expect this to be a problem.
It should say:
[Delete these two sentences.]
Notes:
Page 9 starts with: "Similarly, implementations MUST NOT allow the epoch to wrap" which is a stronger requirement (not allowing to wrap at all vs not allowing reuse within some period), so the weaker requirement should be eliminated to avoid confusion.
Errata ID: 4105
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Manuel Pégourié-Gonnard
Date Reported: 2014-09-08
Section 4.1.2.1 says:
In
DTLS, the receiving implementation MAY simply discard the offending
record and continue with the connection. This change is possible
because DTLS records are not dependent on each other in the way that
TLS records are.
In general, DTLS implementations SHOULD silently discard records with
bad MACs or that are otherwise invalid. They MAY log an error. If a
DTLS implementation chooses to generate an alert when it receives a
message with an invalid MAC, it MUST generate a bad_record_mac alert
with level fatal and terminate its connection state. Note that
because errors do not cause connection termination, DTLS stacks are
more efficient error type oracles than TLS stacks. Thus, it is
especially important that the advice in Section 6.2.3.2 of [TLS12] be
It should say:
See section 4.1.2.7. [And merge the last two sentences above in section 4.1.2.7.]
Notes:
Some text is duplicated between 4.1.2.1 and 4.1.2.7, which my cause confusion or give rise to diverging updates in future revisions of this document.
Errata ID: 4642
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dale R. Worley
Date Reported: 2016-03-18
Section 4.1 says:
version
The version of the protocol being employed. This document
describes DTLS version 1.2, which uses the version { 254, 253 }.
The version value of 254.253 is the 1's complement of DTLS version
1.2. This maximal spacing between TLS and DTLS version numbers
ensures that records from the two protocols can be easily
distinguished. It should be noted that future on-the-wire version
numbers of DTLS are decreasing in value (while the true version
number is increasing in value.)
It should say:
Replace "1's complement of DTLS version" with "1's complement
of TLS version":
version
The version of the protocol being employed. This document
describes DTLS version 1.2, which uses the version { 254, 253 }.
The version value of 254.253 is the 1's complement of TLS version
1.2. This maximal spacing between TLS and DTLS version numbers
ensures that records from the two protocols can be easily
distinguished. It should be noted that future on-the-wire version
numbers of DTLS are decreasing in value (while the true version
number is increasing in value.)
Notes:
Clearly this won't confuse the reader, but it is incorrect as written and should be corrected at some time.
Errata ID: 5026
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Timm Korte
Date Reported: 2017-05-31
Section 4.1 says:
length
Identical to the length field in a TLS 1.2 record. As in TLS 1.2,
the length should not exceed 2^14.
It should say:
length
Identical to the length field in a TLS 1.2 record. As in TLS 1.2,
the length MUST NOT exceed 2^14.
Notes:
The originial comment on length in RFC 5246, 6.2.1 is:
length
The length (in bytes) of the following TLSPlaintext.fragment. The
length MUST NOT exceed 2^14.
so it has to be "MUST NOT" - instead of "should not" as currently stated.
Errata ID: 5903
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2019-11-12
Section 1 says:
with the exception that there is no DTLS version of SSLv2 or SSLv3,
It should say:
with the exception that there is no DTLS version of SSLv2, SSLv3, or TLS 1.0,
Notes:
DTLS has versions that match TLS 1.1, 1.2, and (soon) 1.3. DTLS 1.0 corresponds to TLS 1.1.
Errata ID: 8089
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kamil Milewski
Date Reported: 2024-08-23
Section 4.2.2 says:
struct {
HandshakeType msg_type;
uint24 length;
uint16 message_seq; // New field
uint24 fragment_offset; // New field
uint24 fragment_length; // New field
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case hello_verify_request: HelloVerifyRequest; // New type
case server_hello: ServerHello;
case certificate:Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done:ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
} body;
} Handshake;
It should say:
struct {
HandshakeType msg_type;
uint24 length;
uint16 message_seq; // New field
uint24 fragment_offset; // New field
uint24 fragment_length; // New field
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case hello_verify_request: HelloVerifyRequest; // New field
case certificate:Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done:ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
} body; } Handshake;
Notes:
Change the order of cases inside select field to keep it:
1. In ascending order
2. Consistent with the structure in 4.3.2