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 <resea...@bensmyth.com>
>
> 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
