One more note:
You wrote "After Karthik's kind crypto panel review". In fact, he did
not do the review, he outsourced this to Ben Smith, who kindly did a
thorough job (see [1]). The crypto review panel tracker does show
Khartik Bhargavan as reviewer [2] -- not sure why (since Ben did the work).
For the record, the review was requested by you to Stanislav Smyshlyaev
on July 15th and done Nov 12, 2022 (i.e., four months later), after
ample reminders by Stanislav (kudos on him) and triggered by me and
Mohit Sethi poking about this, not your own actions.
A rationale for the crypto review was never formulated (there already
been two before [even though the review panel page only shows one) and I
can only hope it was not a "fishing expedition".
Ref: [1]
https://mailarchive.ietf.org/arch/msg/crypto-panel/qB5WvocRX9o_UyOdeHw_L2GSaBY/
[2] https://trac.ietf.org/trac/irtf/wiki/Crypto%20Review%20Panel
On 2022-02-09 6:06 p.m., Rene Struik wrote:
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 <[email protected]> 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
[email protected] 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: [email protected]
To: Rene Struik <[email protected]>
<mailto:[email protected]>
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:[email protected] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
--
email:[email protected] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
--
email:[email protected] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
_______________________________________________
Lwip mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lwip
