[TLS] [Errata Verified] RFC8996 (7103)

RFC Errata System <rfc-editor@rfc-editor.org> Wed, 17 January 2024 01:20 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 CF55EC15155F; Tue, 16 Jan 2024 17:20:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.658
X-Spam-Level:
X-Spam-Status: No, score=-1.658 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no 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 x1kCitfur6JX; Tue, 16 Jan 2024 17:20:18 -0800 (PST)
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 0B8E1C151553; Tue, 16 Jan 2024 17:20:17 -0800 (PST)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id C4CE81BA410B; Tue, 16 Jan 2024 17:20:17 -0800 (PST)
To: mt@lowentropy.net, Kathleen.Moriarty.ietf@gmail.com, stephen.farrell@cs.tcd.ie
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: paul.wouters@aiven.io, iesg@ietf.org, tls@ietf.org, iana@iana.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20240117012017.C4CE81BA410B@rfcpa.amsl.com>
Date: Tue, 16 Jan 2024 17:20:17 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/1Lj-qJwM7tgviMKO61QgdJbDQEU>
Subject: [TLS] [Errata Verified] RFC8996 (7103)
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: Wed, 17 Jan 2024 01:20:21 -0000

The following errata report has been verified for RFC8996,
"Deprecating TLS 1.0 and TLS 1.1". 

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7103

--------------------------------------
Status: Verified
Type: Editorial

Reported by: Martin Thomson <mt@lowentropy.net>
Date Reported: 2022-08-24
Verified by: Paul Wouters (IESG)

Section: GLOBAL

Original Text
-------------
<a href="https://www.rfc-editor.org/rfc/rfc%E2%80%8B%204162"
class="eref">​ 4162</a>

Corrected Text
--------------
<a href="https://www.rfc-editor.org/rfc/rfc4162"
class="eref">​4162</a>

Notes
-----
(Note: the line wrapping here is mine; the errata tool assumes that this is text, so it won't accept long lines.)

The text for this specification is OK, but the HTML rendering has some hard-to-notice errors in the "Updates" field in the metadata block that is being caused by errors in the XML source.

The XML source includes a number of Unicode zero width space characters (U+200B) after commas in the rfc@updates attribute.  xml2rfc is unable to handle these characters correctly, treating them - and the space that follows - as part of the RFC number.  It generates the bad link as you see above.

This can be addressed in xml2rfc, maybe, but this is probably not XML we want to permit.

Paul Wouters (AD): Verified, as this RFC won't get any updates.

--------------------------------------
RFC8996 (draft-ietf-tls-oldversions-deprecate-12)
--------------------------------------
Title               : Deprecating TLS 1.0 and TLS 1.1
Publication Date    : March 2021
Author(s)           : K. Moriarty, S. Farrell
Category            : BEST CURRENT PRACTICE
Source              : Transport Layer Security
Area                : Security
Stream              : IETF
Verifying Party     : IESG