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

From: RFC Errata System <[email-masked]>
Date: Mon, 14 Feb 2022 21:42:01 -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/eid5758

--------------------------------------
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.1.

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

Corrected Text
--------------
                          (p+3)/8          (p-5)/8
                 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:52:02 -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: Alexey Melnikov <[email-masked]>
Date: Wed, 16 Feb 2022 10:54:47 +0000

Hi Rene,

On 15/02/2022 20:52, 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).

Your objection is noted.

The errata "Held for Document Update" state is basically for thing which 
are not wrong, but were not necessarily considerations when the 
corresponding RFC was published. It doesn't actually mean that the 
proposed change will be incorporated as is, if the RFC is revised. It is 
also not a guaranty that the RFC will be revised at all.

In this case CFRG chairs didn't think that accepting this erratum was 
right, because this was not discussed or intended in the RG at the time 
the document was published. Rejecting is also seemed wrong, as the new 
formula is not wrong. Thus "Held for Document Update".

> 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.
>>