Hi Rene, There is no substantiation of claims from me because only conditional or hypothetical claims are made -- "there is a question of whether NISTS's publications are internally consistent", "it is perhaps conceivable", "I am hearing the sentiment [from Ilari]", etc. My remarks are an attempt to mediate in the discussion and help you understand the points that I think Ilari is trying to make, so that the conversation can actually reach a resolution instead of lingering on and on. The "ethical" point is (to me) a natural corollary of the position I see Ilari taking, and so I hope you will see that topic as part of the conversation that needs to be had.
As I have already said in earlier messages on this topic, I do not consider myself competent to make a decisive assessment of the question of SHA3/SHAKE bit order for ECDSA, and must defer to others to figure out the actual answer. I believe that at least three people have independently tried to reach out to NIST to get an answer, but I haven't heard any updates on those processes recently. As far as RFC 8692, I reviewed that document in June 2019, well before I was aware of the potential issue of bit vs byte order in SHA-3/SHAKE output (as a non-expert, I don't think one could reasonably expect me to independently discover it). If, per the previous paragraph, we do reach a conclusion that there is an issue, then yes, of course I would call for changing RFC 8692. But I do not *know* there is a problem, and so find it hard to advocate for changing RFC 8692 based on the information available to date. I am sorry that you have been waiting for months to hear back from me in those other threads. There are others that are in that position as well, and it is not something I am proud of. I expect to increase the priority of this LWIG document once the CFRG crypto-panel review is addressed and it can come back in front of the IESG for evaluation. -Ben On Wed, Dec 01, 2021 at 02:47:30PM -0500, Rene Struik wrote: > Well, this is quite a blanket statement, without any substantiation of > claims. > > If there would have been an issue, I would have expected you to > immediately call for withdrawing RFC 8692 [1], where - according to the > IESG ballot evaluation record [2] - you did not bring any conversion > issues up yourself. Instead, I have been waiting for over half a year > for a follow-up email on suggested resolution of a few small comments > you had on the draft (and still have not heard back to this date on the > June 9, 2021 email). > > If you believe nothing of NIST can be trusted, I would have expected an > email marked "extremely urgent - all ietf" with any substantiation of > claims so that one can roll up one's sleeves and verify this and define > follow-up actions accordingly. Instead, I have not seen anything of this > type. > > Given this, I have to say I am struggling with the ethical remarks. > > Ref: [1] RFC 8692 - Internet X.509 Public Key Infrastructure, Additional > Algorithm Identifiers for RSASSA-PSS and ECDSA Using SHAKEs (December 2019) > [2] https://datatracker.ietf.org/doc/rfc8692/ballot/ > > On 2021-12-01 2:26 p.m., Benjamin Kaduk wrote: > > On Wed, Dec 01, 2021 at 02:16:10PM -0500, Rene Struik wrote: > >> Please note, however, have no impact on the specification of ECDSA and > >> the iana cose codepoints for the invocations with SHAKE* functionality. > > I think there is a question about whether all of NISTs publications > > (including examples) are internally consistent. It is perhaps conceivable > > that NIST would choose to make the published examples (and implementations > > that used them as test vectors) the "correct" version and change the ECDSA > > (or SHA-3/SHAKE) specification to resolve such an inconsistency, so I am > > relucant to agree to a "no impact" determination. (Note that due to > > illness and a busy schedule I am not caught up on all the relevant mail, so > > maybe I missed some important previous traffic on this topic.) > > > >> To be frank: your comment is just about an (in your mind) one-line > >> glitch in two informational examples I included as courtesy to readers > >> to illustrate a specification. > > I do not think that the scope of Ilari's concerns is limited to just this > > "one-line glitch". I am hearing the sentiment that NIST has set things up > > with a significant risk of a harmful "gotcha" for implementations, and that > > by specifying codepoints for ECDSA with SHAKE* we are enabling that > > "gotcha" and thereby incurring an ethical responsibility to include a > > prominent disclaimer about the "gotcha" and how to avoid it. This is not > > limited to the examples and we incur the responsibility just by specifying > > the combination of ECDSA and SHAKE*, independently of whether we provide > > examples of such functionality. > > > > -Ben > > > -- > email: [email protected] | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 287-3867 > _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
