[Lwip] (I can't take this any more? Does anyone else?) Re: Fwd: New Version Notification for draft-ietf-lwig-curve-representations-23.txt

[Rene Struik <[e-mail]>]

Hi Erik:

There have been no changes to the iana section with rev23, as you can 
see from my January 21, 2022 note to the LWIG WG  mailing list (i.e., 3 
weeks - one day ago). I also gave you a heads up in the emails you did 
not reply to. The previous draft (Rev22) was posted Oct 25, 2021, or 
almost four months ago.

If you did not trust my reporting to the LWIG WG, you could easily have 
compared drafts using the rfcdiff tool and would have found *zero* 
changes w.r.t. IANA sections there:

https://www.ietf.org/rfcdiff?url1=draft-ietf-lwig-curve-representations-22&url2=draft-ietf-lwig-curve-representations-23

Rev22 of the draft made an ECDSA w/ SHAKE256 code point assignment, as 
result of communication with Ben Kaduk on June 14, 2021, 12.49pm EST 
(and, yes, you were on all those emails), see, e.g., my Nov 7, 2021, 1pm 
EST "reminder of the reminder of the reminder" email to the Cose WG:

https://mailarchive.ietf.org/arch/msg/cose/n-AJuClmhAUx0zi5PSXruK49CZI/

You have not responded to any offline technical correspondence over the 
last year and have plagiarized Mohit Sethi's shepherd summary when you 
had to write something, and all lwig WG documents on the 
https://datatracker.ietf.org/wg/lwig/documents/ show you as (colored in 
dark red) action holders for half a year or more.

Is it really okay to try and put yet another spoke in the wheel? Why?

With all respect, you have been sleeping at the wheel and dragging your 
feet for over a year now, where you have not stood by any agreement 
during offline calls (that included other IESG members and LWIG coChair 
Mohit Sethi). From a security engineering perspective, all behavior 
seems to be cryptographically indistinguishable from a prolonged 
denial-of-service attack.

Why did you put your candidacy forward to run for another term as AD, if 
you have a long history of not wishing to do the work, not returning 
emails or voice mail messages, and having proven yourself so unreliable 
that your role seems nothing else than an officially sanctioned, 
unaccountable spoke-in-the-wheel.

@IETF Chair:
I think this is embarrassing, infuriating to authors who do the work, 
and the entire IETF community unworthy. Is this the kind of role model 
IETF expects of people who were elected as IESG members and Area 
Directors and even reran? I do not know about IETF processes, but isn't 
part of the selection process for people that they presumably promise to 
be reliable advocates of the groups they ran for the AD role for, act 
timely, think collaboratively, etc?

If this isn't a fire-able offense with cause, then what is? If this is 
okay to others in the IESG, isn't everyone culpible?

Rene (I can't take this bull**** any more; nor should anyone else who 
has aspirations in life, imho; this is deeply pathetic, and an 
engineering organization unworthy)


On 2022-02-09 4:46 p.m., Erik Kline wrote:
> [IESG to bcc]
>
> (I had a couple of draft replies to some of your other emails, but 
> hadn't sent any.)
>
> After Karthik's kind crypto panel review I figured that draft -23 was 
> as ready as can be to come back to a telechat. I had intended, 
> however, to have one last look at the IANA section since the IANA 
> expert review state is still marked "Issues identified".
>
> If you think you've addressed all the IANA expert review comments, 
> then I guess that's okay.  I'll try to see if I can request an IANA 
> expert re-review of draft -23.
>
> On Wed, Feb 9, 2022 at 7:58 AM Rene Struik <[e-mail]> wrote:
>
>     Dear Erik:
>
>     Could you please make sure the lwig curve draft ends up on the
>     iesg telechat agenda again asap?
>
>     I think we should (and easily can) get this draft done before
>     there is another IESG roster change (due to AD changes in March).
>     Next week, it will be precisely one year this draft was first put
>     on the iesg telechat agenda (Feb 18, 2021, to be precise). Let us
>     make sure we do not need candles to "celebrate" one year of zero
>     progress.
>
>     Thanks for your help!
>
>     Apologies for sending this message via the mailing list: however,
>     for some reason, none of my offline email messages sent to you
>     since January 13, 2022 seemed to have reached you (or, at least,
>     have been replied to). I did see other emails from the
>     [e-mail] address, so presume that address still works (if
>     this assumption is incorrect, please let me know).
>
>     Rene
>
>
>     On 2022-01-21 6:32 p.m., Rene Struik wrote:
>>
>>     Dear colleagues:
>>
>>     I updated the lwig curve draft, so as to take into account (1)
>>     another crypto review panel review this draft was subjected to by
>>     the powers that be; (2) discussions on ECDSA with the SHA3 family
>>     hash functions that took place on the COSE mailing list and
>>     offline Nov-early January.
>>
>>     Changes:
>>
>>     a) Section 7 (Implementation Status): included reference to
>>     ANSSI's (French information security agency) use of lwig curve
>>     draft, including motivations (hooray);
>>
>>     b) Appendix B.1 (Elliptic Curve Nomenclature): made definition of
>>     isomorphic curves in Appendix B.1 more precise, via one-sentence
>>     change (zero impact on draft, but done for completeness);
>>
>>     c) Appendix I (Data Conversions): added Definition of ASCII
>>     symbols (with reference to RFC 20);
>>
>>     d) Appendix Q (ECDSA): corrected numerical examples for ECDSA w/
>>     Wei25519 and SHAKE-128 (Appendix Q.3.2) and ECDSA w/ Wei448 and
>>     SHAKE-256 (Appendix Q.3.3). Here, it turned out that the Python
>>     code in Sage that I used incorrectly implements the FIPS 202
>>     specification of SHAKE128 and SHAKE256. To do this properly, I
>>     implemented all SHA3 functions from scratch on the bit-level and
>>     had this vetted independently via contacts at NIST. To indicate
>>     that ECDSA w/ Wei448 and SHAKE256 uses FIPS 202-conformant
>>     SHAKE256, I added in Section 4.3 as reference to FIPS 202 "see
>>     Section 6.3 of [FIPS 202]"). BTW - adding ASCII (point c) above)
>>     above was motivated by desire to avoid bit/byte-ordering
>>     ambiguity and set the record straight.
>>
>>     I made a few (very few) typographical and cosmetic changes
>>     throughout the document, in an attempt to make the crypto review
>>     panel reviewer happy. (Time will tell.)
>>
>>     I hope this helps.
>>
>>     Best regards, Rene
>>
>>     -------- Forwarded Message --------
>>     Subject: 	New Version Notification for
>>     draft-ietf-lwig-curve-representations-23.txt
>>     Date: 	Fri, 21 Jan 2022 14:56:26 -0800
>>     From: 	[e-mail]
>>     To: 	Rene Struik <[e-mail]>
>>     <mailto:[e-mail]>
>>
>>
>>
>>
>>     A new version of I-D, draft-ietf-lwig-curve-representations-23.txt
>>     has been successfully submitted by Rene Struik and posted to the
>>     IETF repository.
>>
>>     Name: draft-ietf-lwig-curve-representations
>>     Revision: 23
>>     Title: Alternative Elliptic Curve Representations
>>     Document date: 2022-01-21
>>     Group: lwig
>>     Pages: 150
>>     URL:
>>     https://www.ietf.org/archive/id/draft-ietf-lwig-curve-representations-23.txt
>>     Status:
>>     https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/
>>     Htmlized:
>>     https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations
>>     Diff:
>>     https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-curve-representations-23
>>
>>     Abstract:
>>     This document specifies how to represent Montgomery curves and
>>     (twisted) Edwards curves as curves in short-Weierstrass form and
>>     illustrates how this can be used to carry out elliptic curve
>>     computations leveraging existing implementations and specifications
>>     of, e.g., ECDSA and ECDH using NIST prime curves. We also provide
>>     extensive background material that may be useful for implementers of
>>     elliptic curve cryptography.
>>
>>
>>
>>
>>     The IETF Secretariat
>>
>>
>
>     -- 
>     email:[e-mail]  | Skype: rstruik
>     cell: [phone] | US: [phone]
>

-- 
email:[e-mail]  | Skype: rstruik
cell: [phone] | US: [phone]