RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 8 records.

Status: Reported (8)

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.

Report New Errata



Advanced Search