errata logo graphic

Found 3 records.

Status: Verified (1)

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

Source of RFC: tls (sec)

Errata ID: 1585

Status: Verified
Type: Technical

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)


Status: Reported (1)

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

Source of RFC: tls (sec)

Errata ID: 2390

Status: Reported
Type: Editorial

Reported By: Juho Vähä-Herttua
Date Reported: 2010-07-23

Section 6.2.3.3 says:

   The additional authenticated data, which we denote as
   additional_data, is defined as follows:

      additional_data = seq_num + TLSCompressed.type +
                        TLSCompressed.version + TLSCompressed.length;

   where "+" denotes concatenation.

   The aead_output consists of the ciphertext output by the AEAD
   encryption operation.  The length will generally be larger than
   TLSCompressed.length, but by an amount that varies with the AEAD
   cipher.  Since the ciphers might incorporate padding, the amount of
   overhead could vary with different TLSCompressed.length values.  Each
   AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes.
   Symbolically,

It should say:

   The additional authenticated data, which we denote as
   additional_data, is defined as follows:

      additional_data = seq_num + TLSCompressed.type +
                        TLSCompressed.version + TLSCompressed.length;

   where "+" denotes concatenation.

   The aead_output consists of the ciphertext output by the AEAD
   encryption operation.  The length will generally be larger than
   TLSCompressed.length, but by an amount that varies with the AEAD
   cipher.  Each AEAD cipher MUST NOT produce an expansion of greater
   than 1024 bytes.  Symbolically,

Notes:

I suggest leaving the sentence about padding out. The value for TLSCompressed.length is required by additional_data for both encryption and decryption. Therefore, it must be possible to determine the TLSCompressed.length from the ciphertext before decryption.

In practice this is done by subtracting the integrity check value length from the ciphertext length, where the integrity check value length is defined by each AEAD cipher separately. If the cipher incorporates variable padding, it is impossible to calculate the TLSCompressed.length without an explicit value sent for each ciphertext separately. Therefore to avoid confusion, it would be better not to mention anything about padding at all.

(issue discussed on tls@ietf.org and with Eric Rescorla, result of both discussions was that padding in AEAD ciphers doesn't seem to be possible with the current specification)


Status: Held for Document Update (1)

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

Source of RFC: tls (sec)

Errata ID: 2165

Status: Held for Document Update
Type: Editorial

Reported By: Nikolai Malykh
Date Reported: 2010-04-19
Held for Document Update by: Sean Turner

Section 6.2.3.2 says:

   Example: If the block length is 8 bytes, the content length
   (TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes,
   then the length before padding is 82 bytes (this does not include the



Dierks & Rescorla           Standards Track                    [Page 23]

RFC 5246                          TLS                        August 2008


   IV.  Thus, the padding length modulo 8 must be equal to 6 in order to
   make the total length an even multiple of 8 bytes (the block length).
   The padding length can be 6, 14, 22, and so on, through 254.  If the
   padding length were the minimum necessary, 6, the padding would be 6
   bytes, each containing the value 6.  Thus, the last 8 octets of the
   GenericBlockCipher before block encryption would be xx 06 06 06 06 06
   06 06, where xx is the last octet of the MAC.

It should say:

   Example: If the block length is 8 bytes, the content length
   (TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes,
   then the length before padding is 82 bytes (this does not include the



Dierks & Rescorla           Standards Track                    [Page 23]

RFC 5246                          TLS                        August 2008


   IV).  Thus, the padding length modulo 8 must be equal to 6 in order to
   make the total length an even multiple of 8 bytes (the block length).
   The padding length can be 6, 14, 22, and so on, through 254.  If the
   padding length were the minimum necessary, 6, the padding would be 6
   bytes, each containing the value 6.  Thus, the last 8 octets of the
   GenericBlockCipher before block encryption would be xx 06 06 06 06 06
   06 06, where xx is the last octet of the MAC.