There are two scalar multiplications involved. The first, as part of key generation, indeed passes in a known constant to the u value and outputs the byte string that goes into the key share. The second, the ECDH operation itself, passes in the peer key share and results in the shared secret. In the first call, the key share is the output. In the second, the key share is the input. https://tools.ietf.org/html/rfc7748#section-6.1
But I agree it's not particularly clear. Perhaps it should have said something like: For X25519 and X448, the contents of the public value are the K_A and K_B values described in section 6 of [RFC7748]. This is 32 bytes for X25519 and 56 bytes for X448. On Mon, Aug 5, 2019 at 9:43 AM Patrick Kelsey <pat.kel...@notforadio.com> wrote: > I brought this up to Ekr at IETF 105, and he said he hadn't seen this > particular errata, so here's a bump to the top of the list. > > As it's now been about a year that this errata has remained in the initial > state, I think it might be worth having a look at and advancing to the next > state, if for no other reason than avoidance of the mistaken external > impression that there is longstanding uncertainty about a report that part > of the document says that a private key is to be put on the wire. > > -Pat > > On Mon, Aug 27, 2018 at 11:30 PM RFC Errata System < > rfc-edi...@rfc-editor.org> wrote: > >> The following errata report has been submitted for RFC8446, >> "The Transport Layer Security (TLS) Protocol Version 1.3". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5483 >> >> -------------------------------------- >> Type: Technical >> Reported by: Patrick Kelsey <pat.kel...@notforadio.com> >> >> Section: 4.2.8.2 >> >> Original Text >> ------------- >> For X25519 and X448, the contents of the public value are the byte >> string inputs and outputs of the corresponding functions defined in >> [RFC7748]: 32 bytes for X25519 and 56 bytes for X448. >> >> Corrected Text >> -------------- >> For X25519 and X448, the contents of the public value are the byte >> string outputs of the corresponding functions defined in [RFC7748]: 32 >> bytes for X25519 and 56 bytes for X448. >> >> Notes >> ----- >> Per Section 7.4.2 of this RFC and Section 6 of RFC7748, the byte string >> inputs to the corresponding ECDH scalar multiplication function are the >> private key and the u-coordinate of the standard public base point, the >> former of which of course must not be transmitted and the latter of which >> is a known constant. >> >> >From another perspective, including the byte string inputs in the >> contents of the public value would contradict the resulting content sizes >> given at the end of the cited paragraph as well as the statement in Section >> 7.4.2 that the public key put into the KeyShareEntry is the output of ECDH >> scalar multiplication function. >> >> 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. >> >> -------------------------------------- >> RFC8446 (draft-ietf-tls-tls13-28) >> -------------------------------------- >> Title : The Transport Layer Security (TLS) Protocol Version >> 1.3 >> Publication Date : August 2018 >> Author(s) : E. Rescorla >> Category : PROPOSED STANDARD >> 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 https://www.ietf.org/mailman/listinfo/tls
