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

RFC Errata System <rfc-editor@rfc-editor.org> Fri, 01 May 2020 05:33 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879AB3A080B for <tls@ietfa.amsl.com>; Thu, 30 Apr 2020 22:33:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LFGy0gWpf6a for <tls@ietfa.amsl.com>; Thu, 30 Apr 2020 22:33:36 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34F643A07F9 for <tls@ietf.org>; Thu, 30 Apr 2020 22:33:36 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 91992F40750; Thu, 30 Apr 2020 22:33:18 -0700 (PDT)
To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: research@bensmyth.com, tls@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20200501053318.91992F40750@rfc-editor.org>
Date: Thu, 30 Apr 2020 22:33:18 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/VUhzHdfGyZq-i0Vqt33rFO02lVA>
Subject: [TLS] [Technical Errata Reported] RFC8446 (6152)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 May 2020 05:33:38 -0000

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 <research@bensmyth.com>

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