[TLS] [Errata Verified] RFC8446 (7250)

RFC Errata System <rfc-editor@rfc-editor.org> Fri, 29 March 2024 01:06 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 5894BC151997; Thu, 28 Mar 2024 18:06:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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 SnVxM_SEt6q6; Thu, 28 Mar 2024 18:06:50 -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 78B52C169410; Thu, 28 Mar 2024 18:06:50 -0700 (PDT)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id 4B8AA191A4B4; Thu, 28 Mar 2024 18:06:50 -0700 (PDT)
To: aland@freeradius.org, ekr@rtfm.com
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: <20240329010650.4B8AA191A4B4@rfcpa.amsl.com>
Date: Thu, 28 Mar 2024 18:06:50 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/dgY6MhONHgJW87z3uX2WGQavCBA>
Subject: [TLS] [Errata Verified] RFC8446 (7250)
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 01:06:54 -0000

The following errata report has been verified 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/eid7250

--------------------------------------
Status: Verified
Type: Technical

Reported by: Alan DeKok <aland@freeradius.org>
Date Reported: 2022-11-14
Verified by: Paul Wouters (IESG)

Section: 4.6.1

Original Text
-------------
   The client MAY use this PSK for future handshakes by including the
   ticket value in the "pre_shared_key" extension in its ClientHello
   (Section 4.2.11).

Corrected Text
--------------
(to add)

  Where the client does not support session tickets, this extension MUST be ignored.

Notes
-----
I've seen a TLS implementation which doesn't implement session tickets.  That's fine, but the implementation doesn't *ignore* session tickets it receives.  Instead, it treats reception of the ticket as un recoverable error, and drops the TLS connection.

It's also worth adding a note to section 4.2 at the bottom of page 38.  To note that in general, f an extension isn't supported AND doesn't materially affect the TLS exchange, THEN it should be ignored.

i.e. there's nothing in the spec which mentions Postel's law "be conservative in what you send, be liberal in what you accept".  So implementors reading this document are free to do all kinds of odd things.

In addition, the text in Section 4.2 at the bottom of page 38 says:

"
      Designers
      and implementors should be aware of the fact that until the
      handshake has been authenticated, active attackers can modify
      messages and insert, remove, or replace extensions.
"

The implicit conclusion here is that an implementation receiving extensions must sanity check them.  e.g. an attacker adding an undefined / unknown extension should not cause the entire session to be torn down.

Paul Wouters(AD): Resolved but with the Corrected Text:

The client MAY use this PSK for future handshakes by including the ticket value in the "pre_shared_key" extension in its ClientHello (Section 4.2.11). Clients which receive a NewSessionTicket message but do not support resumption MUST silently ignore this message.

--------------------------------------
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