[TLS] [Technical Errata Reported] RFC8446 (7620)
RFC Errata System <rfc-editor@rfc-editor.org> Mon, 28 August 2023 11:02 UTC
Return-Path: <wwwrun@rfcpa.amsl.com>
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 3747AC14CE5E for <tls@ietfa.amsl.com>; Mon, 28 Aug 2023 04:02:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.468
X-Spam-Level:
X-Spam-Status: No, score=-4.468 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, RDNS_NONE=0.793, SPF_HELO_SOFTFAIL=0.732, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvFivlz5ba7L for <tls@ietfa.amsl.com>; Mon, 28 Aug 2023 04:02:18 -0700 (PDT)
Received: from rfcpa.amsl.com (unknown [50.223.129.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 843A1C151536 for <tls@ietf.org>; Mon, 28 Aug 2023 04:02:18 -0700 (PDT)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id 37E627FDEA; Mon, 28 Aug 2023 04:02:18 -0700 (PDT)
To: ekr@rtfm.com, rdd@cert.org, paul.wouters@aiven.io, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com
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: <20230828110218.37E627FDEA@rfcpa.amsl.com>
Date: Mon, 28 Aug 2023 04:02:18 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/CoAEG9dGbKh4jUkfFtFfYjBkRSs>
Subject: [TLS] [Technical Errata Reported] RFC8446 (7620)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 28 Aug 2023 11:02:22 -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/eid7620 -------------------------------------- Type: Technical Reported by: Ben Smyth <research@bensmyth.com> Section: 6.1 Original Text ------------- Each party MUST send a "close_notify" alert before closing its write side of the connection, unless it has already sent some error alert. This does not have any effect on its read side of the connection. Note that this is a change from versions of TLS prior to TLS 1.3 in which implementations were required to react to a "close_notify" by discarding pending writes and sending an immediate "close_notify" alert of their own. That previous requirement could cause truncation in the read side. Both parties need not wait to receive a "close_notify" alert before closing their read side of the connection, though doing so would introduce the possibility of truncation. Corrected Text -------------- Each party MUST send a "close_notify" alert before closing its write side of the connection, unless it has already sent some error alert. This SHOULD NOT have any effect on the read side of the sender's connection; parties SHOULD receive a "close_notify" alert before closing the read side of their connection. Note that this is a change from versions of TLS prior to TLS 1.3 in which receivers were required to react to a "close_notify" by discarding pending writes and sending an immediate "close_notify" alert of their own. That previous requirement could cause truncation in the read side. Both parties need not wait to receive a "close_notify" alert before closing their read side of the connection, though doing so would introduce the possibility of truncation. Notes ----- As-is there's a specification-level vulnerability: Specification-compliant implementations may be vulnerable to truncation attacks. I suggest using SHOULD NOT & SHOULD for better signposting and to avoid specification-level vulnerability. I also suggest minor tweaks for readability. 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] [Technical Errata Reported] RFC8446 (7620) RFC Errata System
- Re: [TLS] [Technical Errata Reported] RFC8446 (76… Eric Rescorla
- Re: [TLS] [Technical Errata Reported] RFC8446 (76… Ben Smyth
- Re: [TLS] [Technical Errata Reported] RFC8446 (76… Eric Rescorla
- Re: [TLS] [Technical Errata Reported] RFC8446 (76… Viktor Dukhovni
- Re: [TLS] [Technical Errata Reported] RFC8446 (76… Christian Huitema
- Re: [TLS] [Technical Errata Reported] RFC8446 (76… Ben Smyth
- Re: [TLS] [Technical Errata Reported] RFC8446 (76… Eric Rescorla
- Re: [TLS] [Technical Errata Reported] RFC8446 (76… Viktor Dukhovni
- Re: [TLS] [Technical Errata Reported] RFC8446 (76… Ben Smyth
- Re: [TLS] [Technical Errata Reported] RFC8446 (76… Eric Rescorla
- Re: [TLS] [Technical Errata Reported] RFC8446 (76… Ben Smyth
- Re: [TLS] [Technical Errata Reported] RFC8446 (76… Ben Smyth
- Re: [TLS] [Technical Errata Reported] RFC8446 (76… Christian Huitema
- Re: [TLS] [Technical Errata Reported] RFC8446 (76… Eric Rescorla
- Re: [TLS] [Technical Errata Reported] RFC8446 (76… Ben Smyth