Re: [CFRG] (I don't agree) Re: [Errata Held for Document Update] RFC8032 (5758)

[Alexey Melnikov <[e-mail]>]

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

>
> 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:
>> 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 <[e-mail]>
>> 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
>>
>> _______________________________________________
>> CFRG mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/cfrg
>
>