RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 22 records.

Status: Verified (10)

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

Note: This RFC has been obsoleted by RFC 8446

Note: This RFC has been updated by RFC 5746, RFC 5878, RFC 6176, RFC 7465, RFC 7507, RFC 7568, RFC 7627, RFC 7685, RFC 7905, RFC 7919, RFC 8447, RFC 9155

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.

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

Reported By: Benjamin Kaduk
Date Reported: 2015-10-19
Verifier Name: Paul Wouters
Date Verified: 2024-01-16

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.

Paul Wouters (AD): TLS 1.2 has been obsoleted by TLS 1.3 RFC8446. The language in that RFC does not contain the same issue (see https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.2). As such, this is marked as Verified.

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

Reported By: Adrien de Croy
Date Reported: 2016-07-27
Verifier Name: Paul Wouters
Date Verified: 2024-01-16

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.

Paul Wouters (AD): As TLS 1.2 is obsoleted by TLS 1.3, this errata is closed as Verified. In TLS 1.3 in RFC 8447 the text states more clearly: Here, T' occupies n bytes in the data stream, where n is a multiple of the size of T.

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

Reported By: Nikolai Malykh
Date Reported: 2017-01-18
Verifier Name: Paul Wouters
Date Verified: 2024-01-16

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.

Paul Wouters (AD): From errata ID 2865: 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.
This is already fixed in TLS 1.3 RFC8446

Status: Reported (2)

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

Note: This RFC has been obsoleted by RFC 8446

Note: This RFC has been updated by RFC 5746, RFC 5878, RFC 6176, RFC 7465, RFC 7507, RFC 7568, RFC 7627, RFC 7685, RFC 7905, RFC 7919, RFC 8447, RFC 9155

Source of RFC: tls (sec)

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

Reported By: Johannes Görlich
Date Reported: 2021-05-05

Section 9 says:

In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the definition).

It should say:

In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the cipher suite TLS_RSA_WITH_AES_128_GCM_SHA256 (see Appendix A.5 for the definition).

Notes:

A must-be-implement cipher suite should not relay on a bulk encryption algorithm which is vulnerable to plain-text attacks or on a secure hash algorithm which has been proven to be insecure.

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

Reported By: Victor S. Osipov
Date Reported: 2020-07-29

Section 6.2.3.2 says:

IV
The Initialization Vector (IV) SHOULD be chosen at random, and
MUST be unpredictable. Note that in versions of TLS prior to 1.1,
there was no IV field, and the last ciphertext block of the
previous record (the "CBC residue") was used as the IV. This was
changed to prevent the attacks described in [CBCATT]. For block
ciphers, the IV length is of length
SecurityParameters.record_iv_length, which is equal to the
SecurityParameters.block_size.

It should say:

IV
The Initialization Vector (IV) SHOULD be chosen at random, and
MUST be unpredictable. Note that in versions of TLS prior to 1.1,
there was no IV field, and the last ciphertext block of the
previous record (the "CBC residue") was used as the IV. This was
changed to prevent the attacks described in [CBCATT]. For block
ciphers, the IV length is of length
SecurityParameters.record_iv_length, which is equal to the
SecurityParameters.block_length.

Notes:

This is an error here. The structure SecurityParameters hasn't the element block_size.
It has the element block_length.
See in section 6.1:
struct {
ConnectionEnd entity;
PRFAlgorithm prf_algorithm;
BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type;
uint8 enc_key_length;
uint8 block_length;
uint8 fixed_iv_length;
uint8 record_iv_length;
MACAlgorithm mac_algorithm;
uint8 mac_length;
uint8 mac_key_length;
CompressionMethod compression_algorithm;
opaque master_secret[48];
opaque client_random[32];
opaque server_random[32];
} SecurityParameters;

Status: Held for Document Update (4)

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

Note: This RFC has been obsoleted by RFC 8446

Note: This RFC has been updated by RFC 5746, RFC 5878, RFC 6176, RFC 7465, RFC 7507, RFC 7568, RFC 7627, RFC 7685, RFC 7905, RFC 7919, RFC 8447, RFC 9155

Source of RFC: tls (sec)

Errata ID: 4007
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: KIKUCHI Masashi
Date Reported: 2014-06-06
Held for Document Update by: Stephen Farrell
Date Held: 2015-03-24

Section 7.3. says:

Note: To help avoid pipeline stalls, ChangeCipherSpec is an
   independent TLS protocol content type, and is not actually a TLS
   handshake message.

It should say:

Note: To avoid ChangeCipherSpec being transmitted in mix with
   other handshake fragments in one record, ChangeCipherSpec is
   an independent TLS protocol content type, and is not actually
   a TLS handshake message.  To help avoid pipeline stalls, 
   ChangeCipherSpec is sent from both the server and the client.

Notes:

The original text can be read like we can handle ChangeCipherSpec asynchronously.
This is harmful and may be a cause of CCS Injection vulnerability.

Errata ID: 2390
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Juho Vähä-Herttua
Date Reported: 2010-07-23
Held for Document Update by: Sean Turner

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)

Errata ID: 2165
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

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.

Errata ID: 4885
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Wail Yahyaoui
Date Reported: 2016-12-13
Held for Document Update by: Stephen Farrell
Date Held: 2016-12-14

Section 6.1. says:

   server random
      A 32-byte value provided by the server.

      These parameters are defined in the presentation language as:

      enum { server, client } ConnectionEnd;

It should say:

   server random
      A 32-byte value provided by the server.

   These parameters are defined in the presentation language as:

      enum { server, client } ConnectionEnd;

Notes:

The line "These parameters are ..." after the list of parameters is at the same indentation level as the list of parameters, instead of coming back left by one level.

Status: Rejected (6)

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

Note: This RFC has been obsoleted by RFC 8446

Note: This RFC has been updated by RFC 5746, RFC 5878, RFC 6176, RFC 7465, RFC 7507, RFC 7568, RFC 7627, RFC 7685, RFC 7905, RFC 7919, RFC 8447, RFC 9155

Source of RFC: tls (sec)

Errata ID: 4382
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Laura Corcoran
Date Reported: 2015-05-29
Rejected by: EKR
Date Rejected: 2018-06-22

Section 4.3 says:

In the following example, Datum is defined to be three consecutive
   bytes that the protocol does not interpret, while Data is three
   consecutive Datum, consuming a total of nine bytes.

      opaque Datum[3];      /* three uninterpreted bytes */
      Datum Data[9];        /* 3 consecutive 3 byte vectors */

It should say:

In the following example, Datum is defined to be three consecutive
   bytes that the protocol does not interpret, while Data is three
   consecutive Datum, consuming a total of nine bytes.

      opaque Datum[3];      /* three uninterpreted bytes */
      Datum Data[3];        /* 3 consecutive 3 byte vectors */

Notes:

The 9 in "Datum Data[9]" should be a 3 because Datum is a data type that consumes 3 bytes, so as written the Data vector is 27 bytes long. To make it a 9 byte vector the 9 must change to a 3.
--VERIFIER NOTES--
This is not correct. The value here is the number of bytes, not the count of items.

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

Reported By: Stefan Goeman
Date Reported: 2017-06-09
Rejected by: Paul Wouters
Date Rejected: 2024-03-18

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.
--VERIFIER NOTES--
This erratum is incorrect.

Here is the definition of SessionID:
opaque SessionID<0..32>;

The angle brackets mean that it is variable length and the 0..32 means that there is
a one-byte length field.

Errata ID: 5352
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Loic Etienne
Date Reported: 2018-05-09
Rejected by: Eric Rescorla
Date Rejected: 2018-05-10

Section 6.2.3.3. says:

struct {
    opaque nonce_explicit[SecurityParameters.record_iv_length];
    aead-ciphered struct {
        opaque content[TLSCompressed.length];
    };
} GenericAEADCipher;

It should say:

struct {
    opaque nonce_explicit[SecurityParameters.record_iv_length];
    aead-ciphered struct {
        opaque content[TLSCiphertext.length];
    };
} GenericAEADCipher;

Notes:

6.2.3.3. says: "The aead_output consists of the ciphertext output by the AEAD encryption operation. The length will generally be larger than TLSCompressed.length, [...]".

The definition is duplicated at A.1., and needs the same adjustment.
--VERIFIER NOTES--
aead-ciphered is an operator that takes content as the input.

Errata ID: 5409
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Eugene Adell
Date Reported: 2018-06-26
Rejected by: Benjamin Kaduk
Date Rejected: 2018-07-14

Section Appendix A.5 says:

   Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
   reserved to avoid collision with Fortezza-based cipher suites in
   SSL 3.

It should say:

   Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
   reserved to avoid collision with Fortezza-based cipher suites in
   SSL 3. The cipher suite value { 0x00, 0x1E } firstly also assigned to
   Fortezza has been released and has since been be reassigned. 

Notes:

RFC 2712 (Addition of Kerberos Cipher Suites to Transport Layer Security) in its Draft 01 version introduces three new cipher suites colliding with the three Fortezza ones. The Draft 02 version partially corrects that, by moving the Kerberos cipher suites values by two.
This omission of the third cipher suite has never been corrected, and this remains in the same state in the final RFC 2712, RFC 2246 and its successors including this one.

Changing the first Kerberos cipher suite value, or moving all of them, would now not make any sense. Enhancing the note as suggested is probably enough to mention how one Fortezza cipher suite disappeared.
--VERIFIER NOTES--
RFC 5246 is not the appropriate location to document this conflict.

Errata ID: 5535
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Dave Thompson
Date Reported: 2018-10-19
Rejected by: Benjamin Kaduk
Date Rejected: 2018-10-27

Section 4.7 says:

   In DSA, the 20 bytes of the SHA-1 hash are run directly through the
   Digital Signing Algorithm with no additional hashing. ...

It should say:

   In DSA, the bytes of the selected hash are run directly through the
   Digital Signing Algorithm with no additional hashing. ...

Notes:

In 2246 and 4346 this statement (then using the less-accurate spellings DSS and SHA) was correct because only SHA1 was used for DSA (and ECDSA, in 4492, versus SHA1+MD5 for RSA), but 5246 changed this to allow specifying one of several hashes, with selection constrained by the signature_algorithms extension (if present) or CertificateRequest field from the peer.

FIPS 186 actually defines the hashing step as part of signature generation and verification, so it might be even better to make this something like "For DSA, signature generation applies the selected hash [to the contents] and then computes two values, r and s." similar to the way the preceding paragraph of 5246 "In RSA signing" differs from the 2246 and 4346 versions by no longer treating the hashing as separate, but that is a bigger change to an obsoleted document, and arguably problematic because the normative reference is FIPS 186-2; as indicated in Appendix B on page 80, 186-3 which officially allowed DSA to use FIPS 180-3 hashes (not only SHA-1) was released in draft before 5246 but not finalized until after (2006-03 to 2009-06 versus 2008-08).
--VERIFIER NOTES--
As described in the reported Notes, at the time of publication, the DSA specification in force only allowed for the usage of SHA-1. So the document was correct at time of publication and an errata is not appropriate, even though subsequent events have allowed for the usage of a broader set of hash algorithms with DSA.

Errata ID: 3191
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Martin Rex
Date Reported: 2012-04-12
Rejected by: Sean Turner
Date Rejected: 2012-04-19

Section Meta-Data says:

Obsoletes: 3268, 4346, 4366
Updates: 4492

It should say:

Updates: 4492

Notes:

"Obsoletes: 4366" is factually incorrect, because it is impossible to implement TLSv1.1 (rfc4346) or TLSv1.0(rfc2246) from the TLSv1.2 spec alone. (IPv6 does not obsolete IPv4 and HTTP/1.1 does not obsolete HTTP/1.0 either).

"Obsoletes: 4366" is factually incorrect, because some of the TLS extensions defined in rfc4366 do NOT appear in rfc5246 (and were updated by rfc6066). On top of that, in order to implement TLS extensions for TLSv1.0 or TLSv1.1, rfc4366 is indispensible, because it describes the necessary changes to the TLSv1.0 & TLSv1.1 PDUs, information that would be cumbersome to extract from rfc5246 compared to simply using rfc4366.

"Obsoletes: 3268" is factually incorrect, because 3268 is the document needed to implement the AES ciphersuites in implementations of TLS _prior_ to TLSv1.2,
such as TLSv1.0(rfc2246) and TLSv1.1(rfc4346), i.e. to add support for AES ciphersuites to an existing implementation of TLSv1.0, one would use TLSv1.0(rfc2246) plus rfc3268, rather than TLSv1.0 plus some undefined fragments of rfc5246.
--VERIFIER NOTES--
If you're looking to implement TLS 1.1 or TLS 1.0 you should be looking in those earlier specifications not RFC 5246.

One RFC can be obsoleted by more than RFC.

Report New Errata



Advanced Search