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 <tpear...@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
