Re: [EXTERNAL] Re: [Technical Errata Reported] RFC9001 (7785)

[Lucas Pardue <[e-mail]>]

Zahed, please reject this one

On Fri, Jan 26, 2024, at 19:33, Thomas Pearson wrote:
> Yep, Martin's right.  Would have been clearer if the example at the bottom of RFC9000 A3 had shown a full 8 byte variable encoded packet number instead of a 4 byte value.  
> 
> On Fri, Jan 26, 2024 at 11:16 AM Martin Duke <[e-mail]> wrote:
>> *
>> *** CAUTION: This email was sent from an EXTERNAL source. Think before clicking links or opening attachments. ***
>> 
*
>> 
>> 
>> This erratum is incorrect and should be rejected. The full packet number is 62 bits, although it is never expressed as such in the packet number field of the header.
>> 
>> On Fri, Jan 26, 2024 at 10:48 AM RFC Errata System <[e-mail]> wrote:
>>> 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 <[e-mail]>
>>> 
>>> 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
> 
> 
> --
> *Tom Pearson | *Staff Research Engineer
> *Tenable Network Security
*7021 Columbia Gateway Drive, Suite 500*, *Columbia, MD 21046
> 
> [e-mail]
> *W: *410-872-0555 x611 
> tenable.com
>