Subject: [CFRG] [Errata Held for Document Update] RFC8032 (5759)

From: RFC Errata System <[email-masked]>
Date: Mon, 14 Feb 2022 21:42:49 -0800 (PST)

The following errata report has been held for document update 
for RFC8032, "Edwards-Curve Digital Signature Algorithm (EdDSA)". 

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5759

--------------------------------------
Status: Held for Document Update
Type: Technical

Reported by: Franck Rondepierre <[email-masked]>
Date Reported: 2019-06-21
Held by: Stanislav Smyshlyaev (IRSG)

Section: 5.2.

Original Text
-------------
                          (p+1)/4    3            (p-3)/4
                 x = (u/v)        = u  v (u^5 v^3)         (mod p)

Corrected Text
--------------
                          (p+1)/4            (p-3)/4
                 x = (u/v)        =  u (u v)         (mod p)

Notes
-----
 --VERIFIER NOTES-- 
The original text was correct (verified by Nick Sullivan).
01/28/2022: RFC Editor changed status to Reported per discussion with Stanislav V. Smyshlyaev.
02/15/2022: The status is changed to "Held for Document Update" by Stanislav Smyshlyaev. The proposed formulas are correct as well (for the specific case of the EdDSA parameters) and provide a slight efficiency gain.

--------------------------------------
RFC8032 (draft-irtf-cfrg-eddsa-08)
--------------------------------------
Title               : Edwards-Curve Digital Signature Algorithm (EdDSA)
Publication Date    : January 2017
Author(s)           : S. Josefsson, I. Liusvaara
Category            : INFORMATIONAL
Source              : Crypto Forum Research Group
Area                : N/A
Stream              : IRTF
Verifying Party     : IRSG

---

From: Rene Struik <[email-masked]>
Date: Tue, 15 Feb 2022 15:53:38 -0500

Hi Stanislav:

I do not agree: work products of CFRG should try and avoid the tendency 
to try and be the ultimate implementation guidance as well (which we 
should have learned by now).

For CFRG to produce technically sound, well-written documents is hard 
enough. For it to also be a know-all on how to securely or efficiently 
implement things is a recipe for trouble (although it should of course 
not specify things that cannot reasonably be implemented securely).

In this case, while the formulae in RFC 8032 are clumsy, these are 
correct, and the relative merit of changing these (~1% efficiency gain) 
is insufficient to warrant time and effort (including effort to find 
knowledgeable people to review this, explain this to be people who were 
not in the room while changing this, etc.).

As I wrote in my email of Jan 31, 2022, 3.47pm EST:
In my mind, one of the lessons to be learned here is that it would be 
highly recommended to stop the recent practice of CFRG to produce drafts 
that are a curious mix of specification and implementation details 
(which makes of this academic paper generators in the SCA space and, 
moreover, monolithic documents that are hard to maintain of, e.g., adapt 
to an instantiation with another hash function, say SHA-256).

Rene

On 2022-02-15 12:42 a.m., RFC Errata System wrote:
> _______________________________________________
> CFRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

---

From: Rene Struik <[email-masked]>
Date: Tue, 15 Feb 2022 15:55:33 -0500

slightly changed the subject header to facilitate tracking (my apologies 
for resend)

On 2022-02-15 3:53 p.m., Rene Struik wrote:
> Hi Stanislav:
>
> I do not agree: work products of CFRG should try and avoid the 
> tendency to try and be the ultimate implementation guidance as well 
> (which we should have learned by now).
>
> correct, and the relative merit of changing these (~1% efficiency 
> gain) is insufficient to warrant time and effort (including effort to 
> find knowledgeable people to review this, explain this to be people 
> who were not in the room while changing this, etc.).
>
> highly recommended to stop the recent practice of CFRG to produce 
> drafts that are a curious mix of specification and implementation 
> details (which makes of this academic paper generators in the SCA 
> space and, moreover, monolithic documents that are hard to maintain 
> of, e.g., adapt to an instantiation with another hash function, say 
> SHA-256).
>
> Rene
>
>
>> 02/15/2022: The status is changed to "Held for Document Update" by 
>> Stanislav Smyshlyaev. The proposed formulas are correct as well (for 
>> the specific case of the EdDSA parameters) and provide a slight 
>> efficiency gain.
>>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 15 Feb 2022 21:49:41 +0000

Respectfully disagree. IMHO, both IETF and IRTF documents should provide as much guidance on secure efficient implementation of the algorithms they define, as practically possible. After all, the target audience of these documents supposed to be implementers. 

Of course, this assumes  that the authors do have a clue how to implement their algorithm securely and efficiently. 

Regards,
Uri

> On Feb 15, 2022, at 15:56, Rene Struik <[email-masked]> wrote:
> 
> slightly changed the subject header to facilitate tracking (my apologies for resend)
> 
>> I do not agree: work products of CFRG should try and avoid the tendency to try and be the ultimate implementation guidance as well (which we should have learned by now).
>> 
>> For CFRG to produce technically sound, well-written documents is hard enough. For it to also be a know-all on how to securely or efficiently implement things is a recipe for trouble (although it should of course not specify things that cannot reasonably be implemented securely).
>> 
>> In this case, while the formulae in RFC 8032 are clumsy, these are correct, and the relative merit of changing these (~1% efficiency gain) is insufficient to warrant time and effort (including effort to find knowledgeable people to review this, explain this to be people who were not in the room while changing this, etc.).
>> 
>> In my mind, one of the lessons to be learned here is that it would be highly recommended to stop the recent practice of CFRG to produce drafts that are a curious mix of specification and implementation details (which makes of this academic paper generators in the SCA space and, moreover, monolithic documents that are hard to maintain of, e.g., adapt to an instantiation with another hash function, say SHA-256).
>> 
>> Rene
>> 
>>