HFDU is good. Many X25519 implementations won't be concerned about this detail, but others might. We might fix it in one of two ways: twiddle those bits as X25519 requires or note that the private values were the untwiddled/raw values.
On Mon, Mar 18, 2024, at 15:26, Sean Turner wrote: > 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-edi...@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_anth...@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 mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
