Re: [TLS] [Technical Errata Reported] RFC8448 (5645)

Sean Turner <sean@sn3rd.com> Mon, 18 March 2024 04:27 UTC

Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\))
From: Sean Turner <sean@sn3rd.com>
In-Reply-To: <20190228062051.CEED9B81D2D@rfc-editor.org>
Date: Mon, 18 Mar 2024 14:26:51 +1000
Cc: Mai_Anthony@hotmail.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <DA603777-B187-43BF-83D6-07F19B985CFC@sn3rd.com>
References: <20190228062051.CEED9B81D2D@rfc-editor.org>
To: TLS List <tls@ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/rlKNgFTZGg5A0Dsh6ommNQcM1OQ>
Subject: Re: [TLS] [Technical Errata Reported] RFC8448 (5645)
Precedence: list

Hi! This has been lingering for a while, I tend to think we could mark it as HFDU (hold for document update).

spt

> On Feb 28, 2019, at 16:20, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> 
> The following errata report has been submitted for RFC8448,
> "Example Handshake Traces for TLS 1.3".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5645
> 
> --------------------------------------
> Type: Technical
> Reported by: Anthony Mai <Mai_Anthony@hotmail.com>
> 
> Section: 2
> 
> Original Text
> -------------
>   Ephemeral private keys are shown as they are generated in the traces.
> 
> Corrected Text
> --------------
>   Ephemeral private keys are shown as they are generated in the traces.
> Note that X25519 private keys are trimmed in accordance to [RFC 7748]
> Section 5, before use. This is done by clearing bit 0 to 2 of the first
> byte and bit 7 of the last byte. And then set bit 6 of the last byte.
> 
> Notes
> -----
> On page 3,5,16,20,29,43,44,55,57, there are ten X25519 ephemeral private
> keys listed. None of these private key value, when used directly in X25519
> calculation, will yield the associated public key listed. These private key
> values are not the actual values used. Instead up to 5 bits are modified as
> recommended by RFC 7748 section 5. Some implementations may choose NOT to
> do such trimming, and it does not affect the connectivity, as the private
> keys are never sent over the wire and does not affect network behavior.
> 
> Not clarifying how the X25519 private keys were modified before using could
> cause serious confusion. I personally struggled for a day before figuring
> out this little obscure detail.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC8448 (draft-ietf-tls-tls13-vectors-07)
> --------------------------------------
> Title               : Example Handshake Traces for TLS 1.3
> Publication Date    : January 2019
> Author(s)           : M. Thomson
> Category            : INFORMATIONAL
> Source              : Transport Layer Security
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG

[TLS] [Technical Errata Reported] RFC8448 (5645) RFC Errata System
Re: [TLS] [Technical Errata Reported] RFC8448 (56… Sean Turner