[TLS] [Errata Held for Document Update] RFC8446 (6401)

RFC Errata System <rfc-editor@rfc-editor.org> Fri, 29 March 2024 00:54 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 AA75AC169436; Thu, 28 Mar 2024 17:54:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.649
X-Spam-Level:
X-Spam-Status: No, score=-6.649 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, SPF_PASS=-0.001, 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 aojtgKsiovK2; Thu, 28 Mar 2024 17:54:39 -0700 (PDT)
Received: from rfcpa.amsl.com (rfcpa.amsl.com [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 D2A4AC169432; Thu, 28 Mar 2024 17:54:39 -0700 (PDT)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id AA788191A4B4; Thu, 28 Mar 2024 17:54:39 -0700 (PDT)
To: covener@apache.org, ekr@rtfm.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: paul.wouters@aiven.io, iesg@ietf.org, tls@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20240329005439.AA788191A4B4@rfcpa.amsl.com>
Date: Thu, 28 Mar 2024 17:54:39 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/AZMY8_XcpOc-qhflsU-NiDQ2Gyw>
Subject: [TLS] [Errata Held for Document Update] RFC8446 (6401)
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: Fri, 29 Mar 2024 00:54:43 -0000

The following errata report has been held for document update 
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/eid6401

--------------------------------------
Status: Held for Document Update
Type: Technical

Reported by: Eric Covener <covener@apache.org>
Date Reported: 2021-01-20
Held by: Paul Wouters (IESG)

Section: 4.6.2

Original Text
-------------
When the client has sent the "post_handshake_auth" extension (see
Section 4.2.6), a server MAY request client authentication at any
time after the handshake has completed by sending a
CertificateRequest message.  

Corrected Text
--------------
When the client has sent the "post_handshake_auth" extension (see
Section 4.2.6), a server MAY request client authentication during the 
main handshake and/or at any time after the handshake has completed by 
sending a CertificateRequest message.  



Notes
-----
4.6.2 is ambiguous as to whether it forbids "main handshake" (mid-handshake) client 
authentication when the client has sent  the "post_handshake_auth" extension. I think 
the language would be stronger if it were really forbidden, and openssl s_server permits 
this behavior and rfc8740 implies it as well.

The "main handshake" language is adopted from 4.3.2 but "main" could be dropped as 
"handshake" is not ambiguous in 1.3 due to no renegotiation.

--------------------------------------
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
Stream              : IETF
Verifying Party     : IESG