Subject: Re: [TLS] [Technical Errata Reported] RFC8446 (5483)

From: Patrick Kelsey <[email-masked]>
Date: Mon, 5 Aug 2019 09:43:21 -0400

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 <
[email-masked]> 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 <[email-masked]>
>
> 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
>

---

From: David Benjamin <[email-masked]>
Date: Mon, 5 Aug 2019 10:46:27 -0400

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 <[email-masked]>
wrote:

>> >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:
>> -------------
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Patrick Kelsey <[email-masked]>
Date: Mon, 5 Aug 2019 11:23:39 -0400

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 <[email-masked]>
wrote:

>> 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
>>
>>> Title               : The Transport Layer Security (TLS) Protocol
>>> Version 1.3