Subject: [CFRG] Handling the errata for RFC 7748

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Thu, 10 Dec 2020 09:50:00 +0300

Dear CFRG,

There are three reported errata for RFC 7748:
https://www.rfc-editor.org/errata/eid5568
https://www.rfc-editor.org/errata/eid5651
https://www.rfc-editor.org/errata/eid5028

The third one (5028) is an editorial one, I am sure that it improves
clarity of the text, therefore, I support it without doubt.

The first one (5568) is a technical one, with a proposal to change one bit
of the input u-coordinate in the hexadecimal representation (to make it
"consistent" with the base 10 representation). However, the author of 5568
has probably missed that implementations of x25519 should "mask" that bit
after taking a u-coordinate as an input - therefore, the existing text of
RFC does not have any errors there. This is exactly the result of unclear
text that is addressed in the abovementioned third erratum
(5028).Therefore, I would propose to reject the erratum.

The second one (5651) notes that the algorithm description has a mistake in
the description (for calculation of z_2). After implementing the described
algorithm myself (with the MAGMA package) I've obtained the expected
numbers. I suspect that the RFC text is OK, –therefore I would propose to
reject the erratum.

Therefore, I'm planning to approve the third one (5028) and reject the
other two errata (5568 and 5651).

Regards,
Stanislav

---

From: Benoît Viguier <[email-masked]>
Date: Thu, 10 Dec 2020 09:52:12 +0100

Dear CFRG,

I support this decision.

Last Monday, we got the notification that our paper "A Coq proof of the
correctness of X25519 in TweetNaCl" [1]
got accepted. This paper contains two formally mechanized proofs:
- TweetNaCl is correct with respect to the RFC.
- and more importantly that *X25519 in the RFC is correct with respect
to the original paper by Bernstein* [2].

Regards.

[1]: https://benoit.viguier.nl/files/tweetverif.pdf
<https://benoit.viguier.nl/files/tweetverif.pdf>
[2]: https://cr.yp.to/ecdh/curve25519-20060209.pdf
<https://cr.yp.to/ecdh/curve25519-20060209.pdf>

On 12/10/20 7:50 AM, Stanislav V. Smyshlyaev wrote:
> <https://www.rfc-editor.org/errata/eid5568>
> <https://www.rfc-editor.org/errata/eid5651>
> <https://www.rfc-editor.org/errata/eid5028>
>
> The first one (5568) is a technical one, with a proposal to change one
> bit of the input u-coordinate in the hexadecimal representation (to
> make it "consistent" with the base 10 representation). However,
> the author of 5568 has probably missed that implementations of x25519
> should "mask" that bit after taking a u-coordinate as an input -
> therefore, the existing text of RFC does not have any errors there.
> This is exactly the result of unclear text that is addressed in the
> abovementioned third erratum (5028).Therefore, I would propose to
> reject the erratum.
>
> The second one (5651) notes that the algorithm description has a
> mistake in the description (for calculation of z_2). After
> implementing the described algorithm myself (with the MAGMA package)
> I've obtained the expected numbers. I suspect that the RFC text is OK,
> –therefore I would propose to reject the erratum.
>
> _______________________________________________
> CFRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

-- 
Kind regards,

Benoît Viguier
Software Engineer - PhD Student | Cryptography & Formal Methods
Radboud University | Mercator 1, Toernooiveld 212
6525 EC Nijmegen, the Netherlands | www.viguier.nl

---

From: Adam Langley <[email-masked]>
Date: Thu, 10 Dec 2020 09:26:20 -0800

On Wed, Dec 9, 2020 at 10:50 PM Stanislav V. Smyshlyaev <[email-masked]>
wrote:

> The second one (5651) notes that the algorithm description has a mistake
> in the description (for calculation of z_2). After implementing the
> described algorithm myself (with the MAGMA package) I've obtained the
> expected numbers. I suspect that the RFC text is OK, –therefore I would
> propose to reject the erratum.
>

I agree with all of the above. Thanks for checking them.

AGL

---

From: Mike Hamburg <[email-masked]>
Date: Thu, 10 Dec 2020 18:50:09 +0000

> On Dec 10, 2020, at 5:26 PM, Adam Langley <[email-masked]> wrote:
> 
> On Wed, Dec 9, 2020 at 10:50 PM Stanislav V. Smyshlyaev <[email-masked] <mailto:[email-masked]>> wrote:
> Dear CFRG,
> 
> https://www.rfc-editor.org/errata/eid5568 <https://www.rfc-editor.org/errata/eid5568>
> https://www.rfc-editor.org/errata/eid5651 <https://www.rfc-editor.org/errata/eid5651>
> https://www.rfc-editor.org/errata/eid5028 <https://www.rfc-editor.org/errata/eid5028>
> 
> The third one (5028) is an editorial one, I am sure that it improves clarity of the text, therefore, I support it without doubt.
> 
> The first one (5568) is a technical one, with a proposal to change one bit of the input u-coordinate in the hexadecimal representation (to make it "consistent" with the base 10 representation). However, the author of 5568 has probably missed that implementations of x25519 should "mask" that bit after taking a u-coordinate as an input - therefore, the existing text of RFC does not have any errors there. This is exactly the result of unclear text that is addressed in the abovementioned third erratum (5028).Therefore, I would propose to reject the erratum.
> 
> The second one (5651) notes that the algorithm description has a mistake in the description (for calculation of z_2). After implementing the described algorithm myself (with the MAGMA package) I've obtained the expected numbers. I suspect that the RFC text is OK, –therefore I would propose to reject the erratum.
> 
> Therefore, I'm planning to approve the third one (5028) and reject the other two errata (5568 and 5651).
> 

I also agree.  Thanks Stanislav and Benoît.

— Mike

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Tue, 15 Dec 2020 10:07:49 +0300

Many thanks to Benoît, Juan, Mike, Sean and Adam for their comments!

I've handled the errata according to the plan.

Regards,
Stanislav

On Thu, 10 Dec 2020 at 21:50, Mike Hamburg <[email-masked]> wrote:

>> bit of the input u-coordinate in the hexadecimal representation (to make it