Subject: Re: [TLS] [Editorial Errata Reported] RFC8446 (6127)

From: Peter Wu <[email-masked]>
Date: Fri, 1 May 2020 12:59:58 +0200

The current section describes what a client should do when it faces a
HRR, and the referenced bullet point specifies how the HRR "key_share"
extension should be processed.

The errata suggests "clarifying" that point by adding:

> Note: A "key_share" extension may not be supplied in a
> HelloRetryRequest message when a server receives  an "early_data"
> (Section 4.2.10).

I interpret it as:

    If the client sends an "early_data" extension in its Client Hello,
    then the server responding with a HelloRetryRequest MAY include or
    omit the "key_share" extension in the HRR.

That is not a result that is unique to the presence of the "early_data".
Perhaps you misinterpreted the second bullet point in
https://tools.ietf.org/html/rfc8446#page-54

This report does not fix an error, and it adds only more confusion. I
suggest rejecting it.

Kind regards,
Peter

On Fri, Apr 24, 2020 at 02:49:54AM -0700, RFC Errata System wrote:
> 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:
> https://www.rfc-editor.org/errata/eid6127
> 
> --------------------------------------
> Type: Editorial
> Reported by: Ben Smyth <[email-masked]>
> 
> Section: 4.1.2.
> 
> Original Text
> -------------
> If a "key_share" extension was supplied in the HelloRetryRequest,
> replacing the list of shares with a list containing a single
> KeyShareEntry from the indicated group.
> 
> Corrected Text
> --------------
> If a "key_share" extension was supplied in the HelloRetryRequest,
> replacing the list of shares with a list containing a single
> KeyShareEntry from the indicated group. Note: A "key_share" 
> extension may not be supplied in a HelloRetryRequest message 
> when a server receives  an "early_data" (Section 4.2.10).
> 
> Notes
> -----
> 
> 
> 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
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls