RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 6 records.

Status: Reported (5)

RFC 8446, "The Transport Layer Security (TLS) Protocol Version 1.3", August 2018

Source of RFC: tls (sec)

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

Reported By: Patrick Kelsey
Date Reported: 2018-08-28

Section 4.2.8.2 says:

For X25519 and X448, the contents of the public value are the byte
string inputs and outputs of the corresponding functions defined in
[RFC7748]: 32 bytes for X25519 and 56 bytes for X448.

It should say:

For X25519 and X448, the contents of the public value are the byte
string outputs of the corresponding functions defined in [RFC7748]: 32
bytes for X25519 and 56 bytes for X448.

Notes:

Per Section 7.4.2 of this RFC and Section 6 of RFC7748, the byte string inputs to the corresponding ECDH scalar multiplication function are the private key and the u-coordinate of the standard public base point, the former of which of course must not be transmitted and the latter of which is a known constant.

From another perspective, including the byte string inputs in the contents of the public value would contradict the resulting content sizes given at the end of the cited paragraph as well as the statement in Section 7.4.2 that the public key put into the KeyShareEntry is the output of ECDH scalar multiplication function.

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

Reported By: Richard Barnes
Date Reported: 2019-04-01

Section 4.3.2, B.3.2 says:

--- rfc8446.txt	2018-08-10 20:12:08.000000000 -0400
+++ rfc8446.erratum.txt	2019-04-01 15:44:54.000000000 -0400
@@ -3341,7 +3341,7 @@
 
       struct {
           opaque certificate_request_context<0..2^8-1>;
-          Extension extensions<2..2^16-1>;
+          Extension extensions<0..2^16-1>;
       } CertificateRequest;
 
 
@@ -7309,7 +7309,7 @@
 
       struct {
           opaque certificate_request_context<0..2^8-1>;
-          Extension extensions<2..2^16-1>;
+          Extension extensions<0..2^16-1>;
       } CertificateRequest;
 
 

It should say:

--- rfc8446.txt	2018-08-10 20:12:08.000000000 -0400
+++ rfc8446.erratum.txt	2019-04-01 15:44:54.000000000 -0400
@@ -3341,7 +3341,7 @@
 
       struct {
           opaque certificate_request_context<0..2^8-1>;
-          Extension extensions<2..2^16-1>;
+          Extension extensions<0..2^16-1>;
       } CertificateRequest;
 
 
@@ -7309,7 +7309,7 @@
 
       struct {
           opaque certificate_request_context<0..2^8-1>;
-          Extension extensions<2..2^16-1>;
+          Extension extensions<0..2^16-1>;
       } CertificateRequest;
 
 

Notes:

The length of this vector can never 2. It is either 0, if the vector is empty, or >=4, if the vector has at least one extension. Nothing elsewhere in the spec requires a non-zero number of extensions here, so this syntax should allow a zero-length vector.

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

Reported By: Hubert Kario
Date Reported: 2019-10-02

Section 4.2.3 says:

   ECDSA algorithms:  Indicates a signature algorithm using ECDSA
      [ECDSA], the corresponding curve as defined in ANSI X9.62 [ECDSA]
      and FIPS 186-4 [DSS], and the corresponding hash algorithm as
      defined in [SHS].  The signature is represented as a DER-encoded
      [X690] ECDSA-Sig-Value structure.

It should say:

   ECDSA algorithms:  Indicates a signature algorithm using ECDSA
      [ECDSA], the corresponding curve as defined in ANSI X9.62 [ECDSA]
      and FIPS 186-4 [DSS], and the corresponding hash algorithm as
      defined in [SHS].  The signature is represented as a DER-encoded
      [X690] ECDSA-Sig-Value structure as defined in [RFC4492].

Notes:

There is a possibility for confusion as the ECDSA-Sig-Value has two conflicting definitions in authoritative standards. TLS always used the following (see RFC4492):

ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}

but the publicly accessible SECG SEC1 v2.0 (https://www.secg.org/sec1-v2.pdf) defines it like this:

ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER,
a INTEGER OPTIONAL,
y CHOICE { b BOOLEAN, f FieldElement } OPTIONAL
}

I think using the RFC5480 in the Corrected Text would be cleaner than RFC4492, but the former is not an existing reference, so we would need to update section 12 also.

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

Reported By: Mr Laurie Perrin
Date Reported: 2019-10-12

Section 5.1 says:

...

   Application Data messages contain data that is opaque to TLS.
   Application Data messages are always protected.  Zero-length
   fragments of Application Data MAY be sent, as they are potentially
   useful as a traffic analysis countermeasure.  Application Data
   fragments MAY be split across multiple records or coalesced into a
   single record.

It should say:

...

   Application Data messages contain data that is opaque to TLS.
   Application Data messages are always protected.  Zero-length
   fragments of Application Data (i.e. those encapsulating an
   TLSInnerPlaintext record having a content field of length zero)
   MAY be sent, as they are potentially useful as a traffic analysis
   countermeasure. Application Data fragments MAY be split across
   multiple records or coalesced into a single record.

Notes:

In the interest of clarity, it may be prudent to specify the type of record for
which a fragment of length zero is being considered - it cannot be that of the
TLSCiphertext itself, for "Application Data messages are always protected,"
therefore I infer this relates to the TLSInnerPlaintext content field (of
length "TLSPlaintext.length") - i.e. to the TLSPlaintext fragment.

Note: This comment also applies to previous versions of the TLS specification,
in particular with the introduction of the respective text concerning zero-length
fragments in RFC 5246. In TLS 1.2, this would be the GenericXXCipher content
field of length "TLSCompressed.length" - i.e. to the TLSCompressed fragment.

Note: The implications of zero-length records must be considered with respect to
potential vectors for denial of service.

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

Reported By: Daniel Migault
Date Reported: 2019-05-03

Section 2.2. says:


 Figure 3 shows a pair of handshakes in which the first handshake
   establishes a PSK and the second handshake uses it:
 
          Client                                               Server
 
   Initial Handshake:
          ClientHello
          + key_share               -------->
                                                          ServerHello
                                                          + key_share
                                                {EncryptedExtensions}
                                                {CertificateRequest*}
                                                       {Certificate*}
                                                 {CertificateVerify*}
                                                           {Finished}
                                    <--------     [Application Data*]
          {Certificate*}
          {CertificateVerify*}
          {Finished}                -------->
                                    <--------      [NewSessionTicket]
          [Application Data]        <------->      [Application Data]
 
 
   Subsequent Handshake:
          ClientHello
          + key_share*
          + pre_shared_key          -------->
                                                          ServerHello
                                                     + pre_shared_key
                                                         + key_share*
                                                {EncryptedExtensions}
                                                           {Finished}
                                    <--------     [Application Data*]
          {Finished}                -------->
          [Application Data]        <------->      [Application Data]
 
               Figure 3: Message Flow for Resumption and PSK

It should say:


 Figure 3 shows a pair of handshakes in which the first handshake
   establishes a PSK and the second handshake uses it:
 
          Client                                               Server
 
   Initial Handshake:
          ClientHello
          + key_share               -------->
                                                          ServerHello
                                                          + key_share
                                                {EncryptedExtensions}
                                                {CertificateRequest*}
                                                       {Certificate*}
                                                 {CertificateVerify*}
                                                           {Finished}
                                    <--------     [Application Data*]
          {Certificate*}
          {CertificateVerify*}
          {Finished}                -------->
                                    <--------      [NewSessionTicket]
          [Application Data]        <------->      [Application Data]
 
 
   Subsequent Handshake:
          ClientHello
          + key_share*
          + psk_key_exchange_modes        
          + pre_shared_key          -------->

                                                          ServerHello
                                                     + pre_shared_key
                                                         + key_share*
                                                {EncryptedExtensions}
                                                           {Finished}
                                    <--------     [Application Data*]
          {Finished}                -------->
          [Application Data]        <------->      [Application Data]
 
               Figure 3: Message Flow for Resumption and PSK

Notes:

The pre_shared_key requires the pre_share_key extension. As mentioned by Martin Thompson figures do not necessarily guarantee all extensions to be mentioned. However in this case, that would be clarifying to have both extensions mentioned on the figure.

Status: Held for Document Update (1)

RFC 8446, "The Transport Layer Security (TLS) Protocol Version 1.3", August 2018

Source of RFC: tls (sec)

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

Reported By: Daniel Kahn Gillmor
Date Reported: 2019-02-08
Held for Document Update by: Benjamin Kaduk
Date Held: 2019-02-08

Section 4.2.11 says:

In TLS versions prior to TLS 1.3, the Server Name Identification
(SNI) value 

It should say:

In TLS versions prior to TLS 1.3, the Server Name Indication
(SNI) value 

Notes:

RFC 6066 and many other places indicate that the correct expansion for "SNI" is "Server Name Indication", not "Server Name Identification".

Report New Errata