Fair point that there are two scalar multiplications involved on either endpoint in the course of the exchange, that what is being referred to in this section of RFC8446 is the first one, and that some readers might find ambiguity with respect to this that could be addressed with a different approach to the correction than I suggested (in my reading of RFC7748, I found 6.1 clear in establishing that it is the results of the first scalar multiplication that are transmitted).
If an approach like the one you are suggesting is taken, I recommend replacing "are the K_A and K_B values" with "is the K_A or K_B value", as the content of the public value is one of those and not both. -Pat On Mon, Aug 5, 2019 at 10:46 AM David Benjamin <david...@chromium.org> wrote: > 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
