Hi Rene,
On Wed, Dec 01, 2021 at 03:32:24PM -0500, Rene Struik wrote:
> Hi Ben:
>
> With all due respect, one would expect an Area Director to stay away
> from hypothetical and conditional claims (which in this case seem to be
> single-source base, based on Ilari Liusvaara's assessments {where, in
To reiterate: my comments here were intended to mediate in the discussion
between you and Ilari. That is, if you want Ilari to stop raising this
topic, you should (in my opinion) address the questions and concerns as I
phrased them, since I believe that my restatement matches Ilari's intent.
Your answers thus far have addressed only some parts of what I have
understood Ilari to be saying, and thus I expect Ilari to consider his
concerns unaddressed.
> the past, these were consistently inaccurate, but nevertheless quoted}).
> Moreover, one would expect a Security Area Director to be able to look
> up some specs and read this, if this helps, and not simply declare
> oneself incompetent in the matter.
To be clear, I did spend quite some time with the relevant standards, even
going so far as to spend my employer's money to purchase the relevant ANSI
standard. I concluded (as you do downthread) that the standards are clear
and consistent and treat inputs/outputs as bit strings. However, when I
went to go compare what common implementations (openssl, in particular) do
against what the standard says, I ran into some behaviors that I could not
fully explain. NIST provides some examples that include both bitwise and
hex representations of SHA-3 inputs, that helped me understand that part of
implementation behavior, but I don't remember seeing anything that really
provided clarity on the bitstring interpretation of the outputs. I believe
that I wrote this all up back in August and included you on the email, so I
thought you had the benefit of this background on what investigation I have
done myself.
> I do think staying mum for over half a year and throwing other
> gratuitous spokes in the wheel is an AD-role unworthy behavior (but
> perhaps my standards are higher).
I am surprised to see an attempt to mediate an ongoing discussion between
WG participants be characterized as "throwing other gratuitous spokes in
the wheel".
-Ben
>
> 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
