Subject: [TLS] [Technical Errata Reported] RFC8446 (6152)

From: RFC Errata System <[email-masked]>
Date: Thu, 30 Apr 2020 22:33:18 -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:
https://www.rfc-editor.org/errata/eid6152

--------------------------------------
Type: Technical
Reported by: Ben Smyth <[email-masked]>

Section: 4

Original Text
-------------
Clients MUST check for ["supported_versions"] prior to
processing the rest of the ServerHello (although they will have to 
parse the ServerHello in order to read the extension). -- Section 4.2.1.

Upon receipt of a HelloRetryRequest, the client MUST check the
legacy_version, legacy_session_id_echo, cipher_suite, and
legacy_compression_method as specified in Section 4.1.3 and then
process the extensions, starting with determining the version using
"supported_versions". -- Section 4.1.4

Upon receiving a message with type server_hello, implementations MUST
first examine the Random value... -- Section 4.1.3.

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

Notes
-----
These requirements are seemingly conflicting. I suspect checking for "supported_versions" must 
come first, since that may influence subsequent steps, e.g., checking legacy_compression_method 
and the Random value. It doesn't seem to matter whether legacy_version, legacy_session_id_echo, 
cipher_suite, and legacy_compression_method are checked before the Random value, so it doesn't
seem to matter which check is second and which is third. (Noting, as per one of my earlier reports,
dated 28 Apr, Section 4.1.3 defines no checks for legacy_version nor legacy_compression_method. 
Perhaps the latter should be checked to be zero, aborting with alert illegal_parameter if it isn't, as per
Section 4.1.2.)

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