IETF Logo Mail Archive

[Technical Errata Reported] RFC9001 (7785)

RFC Errata System <rfc-editor@rfc-editor.org> Fri, 26 January 2024 18:48 UTC

Return-Path: <wwwrun@rfcpa.amsl.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921F6C1654EC for <quic@ietfa.amsl.com>; Fri, 26 Jan 2024 10:48:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.359
X-Spam-Level:
X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_LOW=-0.7, 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=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 9cX0WdPCe7jJ for <quic@ietfa.amsl.com>; Fri, 26 Jan 2024 10:48:28 -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 0C277C157938 for <quic@ietf.org>; Fri, 26 Jan 2024 10:48:28 -0800 (PST)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id CEAB83E8A8; Fri, 26 Jan 2024 10:48:27 -0800 (PST)
To: mt@lowentropy.net, sean@sn3rd.com, martin.h.duke@gmail.com, zahed.sarker.ietf@gmail.com, matt.joras@gmail.com, lucas@lucaspardue.com
Subject: [Technical Errata Reported] RFC9001 (7785)
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: tpearson@tenable.com, quic@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20240126184827.CEAB83E8A8@rfcpa.amsl.com>
Date: Fri, 26 Jan 2024 10:48:27 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/KGBg1-8OBpjUeEMDttafaCyPEf0>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jan 2024 18:48:32 -0000

The following errata report has been submitted for RFC9001,
"Using TLS to Secure QUIC".

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

--------------------------------------
Type: Technical
Reported by: Tom Pearson <tpearson@tenable.com>

Section: 5.3

Original Text
-------------
The key and IV for the packet are computed as described in
Section 5.1.  The nonce, N, is formed by combining the packet
protection IV with the packet number.  The 62 bits of the
reconstructed QUIC packet number in network byte order are left-
padded with zeros to the size of the IV.  The exclusive OR of the
padded packet number and the IV forms the AEAD nonce.

Corrected Text
--------------
The key and IV for the packet are computed as described in
Section 5.1.  The nonce, N, is formed by combining the packet
protection IV with the packet number.  The 32 bits of the
reconstructed QUIC packet number in network byte order are left-
padded with zeros to the size of the IV.  The exclusive OR of the
padded packet number and the IV forms the AEAD nonce.

Notes
-----
Given the description of packet number reconstruction in RFC9000 section 17.1 and the example in RFC9000 Appendix A3, the length of reconstructed packet number should be 32 bits, not 62 bits.

Instructions:
-------------
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--------------------------------------
RFC9001 (draft-ietf-quic-tls-34)
--------------------------------------
Title               : Using TLS to Secure QUIC
Publication Date    : May 2021
Author(s)           : M. Thomson, Ed., S. Turner, Ed.
Category            : PROPOSED STANDARD
Source              : QUIC
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

v2.23.0 | Report a Bug | By Email