errata logo graphic

Found 4 records.

Status: Reported (4)

RFC6347, "Datagram Transport Layer Security Version 1.2", January 2012

Source of RFC: tls (sec)

Errata ID: 3917

Status: Reported
Type: Technical

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

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: 4104

Status: Reported
Type: Editorial

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

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.


Report New Errata