RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 11 records.

Status: Verified (7)

RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2", August 2008

Note: This RFC has been obsoleted by RFC 8446

Source of RFC: tls (sec)

Errata ID: 1585
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Pasi Eronen
Date Reported: 2008-11-05
Verifier Name: Pasi Eronen
Date Verified: 2009-03-02

Section A.4.2 says:

struct {
    ClientCertificateType certificate_types<1..2^8-1>;
    DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;

It should say:

struct {
    ClientCertificateType certificate_types<1..2^8-1>;
    SignatureAndHashAlgorithm
      supported_signature_algorithms<2^16-1>;
    DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;

Notes:

The definition in Section 7.4.4 (which includes the "supported_
signature_algorithms" field) is the correct one (confirmed
by Eric Rescorla on 2009-02-27)

Errata ID: 2643
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Matt McCutchen
Date Reported: 2010-11-22
Verifier Name: Sean Turner
Date Verified: 2011-03-09

Section E.3 says:

When a TLS-capable server negotiates SSL 2.0 it SHOULD, after
decrypting the ENCRYPTED-KEY-DATA field, check that these 8 padding
bytes are 0x03.  If they are not, the server SHOULD generate a random
value for SECRET-KEY-DATA, and continue the handshake (which will
eventually fail since the keys will not match).

It should say:

When a TLS-capable server negotiates SSL 2.0 it SHOULD, after
decrypting the ENCRYPTED-KEY-DATA field, check that these 8 padding
bytes are not all 0x03.  If they are, the server SHOULD generate a random
value for SECRET-KEY-DATA, and continue the handshake (which will
eventually fail since the keys will not match).

Notes:

The condition is the wrong way around. When the bytes *are* all 0x03, that means the client supports TLS, so there must have been a version rollback attack in order for SSL 2.0 to be negotiated. For example, see the NSS implementation (line number may rot):

https://mxr.mozilla.org/mozilla/source/security/nss/lib/ssl/sslcon.c#1695

Errata ID: 2864
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Alfredo Pironti
Date Reported: 2011-07-19
Verifier Name: Sean Turner
Date Verified: 2012-01-09

Section A.4.2 says:

struct {
    ClientCertificateType certificate_types<1..2^8-1>;
    DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;

--- Fixed by errata 1585 to

struct {
    ClientCertificateType certificate_types<1..2^8-1>;
    SignatureAndHashAlgorithm
      supported_signature_algorithms<2^16-1>;
    DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;

It should say:

struct {
    ClientCertificateType certificate_types<1..2^8-1>;
    SignatureAndHashAlgorithm
      supported_signature_algorithms<2..2^16-2>;
    DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;

Notes:

The supported_signature_algorithms field is a variable length array. As such ceiling and floor should be specified, and they should be multiple of the base type (which is two bytes long in this case).

Errata ID: 2865
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Alfredo Pironti
Date Reported: 2011-07-19
Verifier Name: Sean Turner
Date Verified: 2012-01-09

Section 7.4.4 says:

struct {
    ClientCertificateType certificate_types<1..2^8-1>;
    SignatureAndHashAlgorithm
      supported_signature_algorithms<2^16-1>;
    DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;

It should say:

struct {
    ClientCertificateType certificate_types<1..2^8-1>;
    SignatureAndHashAlgorithm
      supported_signature_algorithms<2..2^16-2>;
    DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;

Notes:

The supported_signature_algorithms field is a variable length array. As such ceiling and floor should be specified, and they should be multiple of the base type (which is two bytes long in this case). See section 7.4.1.4.1 for a valid definition of this field.

Errata ID: 3122
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Daniel Otte
Date Reported: 2012-02-16
Verifier Name: Sean Turner
Date Verified: 2012-05-06

Section A.4. says:

   enum {
       hello_request(0), client_hello(1), server_hello(2),
       certificate(11), server_key_exchange (12),
       certificate_request(13), server_hello_done(14),
       certificate_verify(15), client_key_exchange(16),
       finished(20)
       (255)
   } HandshakeType;

It should say:

   enum {
       hello_request(0), client_hello(1), server_hello(2),
       certificate(11), server_key_exchange (12),
       certificate_request(13), server_hello_done(14),
       certificate_verify(15), client_key_exchange(16),
       finished(20),
       (255)
   } HandshakeType;

Notes:

The comma after finished(20) is missing in the original text.

Errata ID: 3123
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Daniel Otte
Date Reported: 2012-02-16
Verifier Name: Sean Turner
Date Verified: 2012-05-06

Section A.4.2. says:

   struct {
       select (KeyExchangeAlgorithm) {
           case dh_anon:
               ServerDHParams params;
           case dhe_dss:
           case dhe_rsa:
               ServerDHParams params;
               digitally-signed struct {
                   opaque client_random[32];
                   opaque server_random[32];
                   ServerDHParams params;
               } signed_params;
           case rsa:
           case dh_dss:
           case dh_rsa:
               struct {} ;
              /* message is omitted for rsa, dh_dss, and dh_rsa */
           /* may be extended, e.g., for ECDH -- see [TLSECC] */
   } ServerKeyExchange;

It should say:

   struct {
       select (KeyExchangeAlgorithm) {
           case dh_anon:
               ServerDHParams params;
           case dhe_dss:
           case dhe_rsa:
               ServerDHParams params;
               digitally-signed struct {
                   opaque client_random[32];
                   opaque server_random[32];
                   ServerDHParams params;
               } signed_params;
           case rsa:
           case dh_dss:
           case dh_rsa:
               struct {} ;
              /* message is omitted for rsa, dh_dss, and dh_rsa */
           /* may be extended, e.g., for ECDH -- see [TLSECC] */
       };
   } ServerKeyExchange;

Notes:

The '};' which belongs to 'select (KeyExchangeAlgorithm) {' is missing in the original text.

Errata ID: 4109
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Christopher Armstrong
Date Reported: 2014-09-11
Verifier Name: Stephen Farrell
Date Verified: 2015-03-24

Section A.4.2 says:

   opaque ASN.1Cert<2^24-1>;

It should say:

   opaque ASN.1Cert<1..2^24-1>;

Notes:

The appendix definition of ASN.1Cert leaves out the floor of the variable-length vector, which must be specified according to the vector syntax specification in section 4.3. Fortunately, the original definition of ASN.1Cert in section 7.4.2 does specify the floor as 1, so the definition in A.4.2 should be updated to match.

Status: Reported (4)

RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2", August 2008

Note: This RFC has been obsoleted by RFC 8446

Source of RFC: tls (sec)

Errata ID: 4912
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Nikolai Malykh
Date Reported: 2017-01-18

Section A.4.1 says:

   SignatureAndHashAlgorithm
    supported_signature_algorithms<2..2^16-1>;

It should say:

   SignatureAndHashAlgorithm
    supported_signature_algorithms<2..2^16-2>;

Notes:

Error in last sentence. See errata ID 2865.

Errata ID: 5036
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Stefan Goeman
Date Reported: 2017-06-09

Section 7.4.1.2 says:

The ClientHello Structure indicates that a SessionID could be present.
However if I take a wireshark of a TLS session I always see a "Session 
ID Length" field, either with value 0 or value 32

It should say:

In the ClientHello structure and ServerHello structure, include 
a 1 byte "Session ID Length" field.

Notes:

The ClientHello Structure indicates that a SessionID could be present.
However if I take a wireshark of a TLS session I always see a
"Session ID Length" field, either with value 0 or value 32.

Errata ID: 4507
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Benjamin Kaduk
Date Reported: 2015-10-19

Section 7.4.1.2 says:

After sending the ClientHello message, the client waits for a
ServerHello message.  Any handshake message returned by the server,
except for a HelloRequest, is treated as a fatal error.

It should say:

After sending the ClientHello message, the client waits for a
ServerHello message.  Any other handshake message returned by the
server, except for a HelloRequest, is treated as a fatal error.

Notes:

A ServerHello received after a ClientHello should not be treated as a fatal error.

Errata ID: 4750
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Adrien de Croy
Date Reported: 2016-07-27

Section 4.3 Vectors says:

The length of
   an encoded vector must be an even multiple of the length of a single
   element (for example, a 17-byte vector of uint16 would be illegal).

It should say:

The length of
   an encoded vector must be a whole multiple of the length of a single
   element (for example, a 17-byte vector of uint16 would be illegal).

Notes:

Original text implies vectors can only contain even (0,2,4,6,8...) numbers of elements. The example does not resolve this but indicates the intent is that parts of elements are not allowed. It is clear from other examples that odd numbers of elements are permitted.

Report New Errata