Subject: [TLS] [Editorial Errata Reported] RFC8446 (5717)

From: RFC Errata System <[email-masked]>
Date: Thu, 2 May 2019 18:04:13 -0700 (PDT)

The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5717

--------------------------------------
Type: Editorial
Reported by: Daniel Migault <[email-masked]>

Section: 2.2.

Original Text
-------------

 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

Corrected Text
--------------

 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.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC8446 (draft-ietf-tls-tls13-28)
--------------------------------------
Title               : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date    : August 2018
Author(s)           : E. Rescorla
Category            : PROPOSED STANDARD
Source              : Transport Layer Security
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 02 May 2019 21:56:36 -0400

Two fixes required, but then I think HFDU is appropriate:

1. Misspelling of names.

2. The pre_shared_key extension requires the use of the psk_key_exchange_modes extension.

On Fri, May 3, 2019, at 11:04, RFC Errata System wrote:
> 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.
> 
> Instructions:
> -------------
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 2 May 2019 19:11:33 -0700

MT: why do you not think "confirmed"?

-Ekr

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 02 May 2019 22:14:20 -0400

> MT: why do you not think "confirmed"?

It seems like we use HFDU for this sort of thing and it's not like it's strictly *wrong* here.