Hi Ben:
If one had wanted to be consistent in reasoning, one should also have
pulled draft-ietf-hash-algs out of the AUTH48 queue (since July 14, 2021
[1]) and should not have assigned a iana cose code point for shake128
(now, -18, see [2]). None of that happened either, despite these numbers
to be jealously treated as valuable assets.
Ref: [1] https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/history/
[2] https://www.iana.org/assignments/cose/cose.xhtml#algorithms
This being said, as already indicated I will do my own technical due
diligence (on the example E value computation), since do not base my own
findings on hearsay or unverified claims.
Rene
On 2021-12-01 3:22 p.m., Benjamin Kaduk wrote:
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
--
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
