RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Reported (3)

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

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

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: 5717
Status: Reported
Type: Editorial

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

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