On 2021-02-17 9:12 p.m., Benjamin Kaduk wrote:
Hi Rene,
On Wed, Feb 17, 2021 at 08:27:41PM -0500, Rene Struik wrote:
Dear colleagues:
I uploaded v20 of this document. It is my sincere hope that this will
help in making swift progress.
Changes (compared to previous version v19):
- removed the cose iana requests subsections, so as to avoid further
pollution of discussion of this document (which is long overdue to get out).
Is there WG consensus for this action?
RS>> I removed that subsection for now, after the litany of emails with
mixed messaging the last few days (I thought this was what would make
Magnus "happy" and this was something I thought Erik Kline recommended).
I don't know how to play these type of "games", since am completely
bewildered by this.
<<RS
Note that once the draft was adopted by the WG, change control passed to
the WG/the IETF, and your role becomes that of an editor, tasked with
realizing the consensus positions (even when they disagree with your own).
While you retain significant editorial latitude in editorial matters, I
would have expected that matters such as whether or not to request
allocation of IANA codepoints would be a consensus decision
[Excerpt email RS of Feb 16, 2021, 11.50am EST; see
https://mailarchive.ietf.org/arch/msg/lwip/9SH1J3OZoiwMZ8jx49OhOlZOtAg/ ]
The iana cose "bickering" is about the value of 6 one-word character strings, in an otherwise quite
voluminous, since 137 pages, document, where the value could be "new" or "reuse existing"
(i.e., at most six bits of entropy). The current iana cose request may not be perfect. If it requires
improvement, I can write some text to accommodate this *in parallel* to the IESG review.
For the record, I dispute this characterization on several counts.
RS>> BTW - I used the word "bickering" with quotation marks and am a
non-native speaker, but it is the right word for the games being played:
According to sex and relationship therapist Tammy Nelson, PhD, the
clear line between*bickering*and*fighting*when it comes to style
of*arguing*in a relationship is about whether you play dirty. ...
“The problem is not that you*argue*; the problem is whether or not
you resolve your*arguments*,” she says.
I have a long record of non-responsiveness by the "iana cose expert"
(stretching for months, where even nudging people with promised
home-baked applepie to finally get people to be responsive did not work
and iana staff also does not seem to keep an eye on timeliness). The
supposed COSE mailing list "discussions" also did not seem to resolve
anything and seems to be mostly devoid from looking at actual specs,
just presumed behavior of specs (as if considered a blackbox). More
below. <<RS
You say "bickering" where I see legitimate technical concerns that remain
unanswered. (Yes, there was a statement made by one individual about
previous IANA review of the COSE registrations and that statement turned
out to be inaccurate. I note that the statement in question was prefaced
with "to my undersanding" and the author of the statement was quick to
acknowledge the correction.)
I believe that the technical issues raised involve more than just the
character strings (that also correspond to integer values for the CBOR
encoding). In addition to the topic of what class of semantics those
values are to convey, there was also a question raised relating to ECDSA on
Wei25519 and the need to truncate the hash function output to a number of
bits not divisible by 8. In what review of the document I have done so far
I do note a fastidious (possibly excessively so) attention to bit-order of
encoding,
RS>> In security, careful attention to details matters and, in fact, is
imperative. I added the data conversion section and bit/byte-orderings
to compensate for the lack of precision in lots of security-related
internet drafts, which has become a huge problem for practitioners. For
some of the issues with ambiguity, see, e.g.,
[a] Signatures, ECC, Taming the Many EdDSAs, ed25519, cofactor
(Konstantinos Chalkias, Francois Garillot, Valeria Nikolaenko, IACR
ePrint 2020-1244, SSR 2020)
[b] ECC - Provable Security for Ed25519, Theory and Practice (Jacqueline
Brendel, Cas Cremers, Dennis Jackson, Mang Zhao, IACR ePrint 2020-823)
In fact, simply have a look at the dozens of Errata posted on
curve-related documents and one knows enough: "loose specs sink security
ships".
<<RS
but it is not clear to me that proper prominence has been given to
the need to pay attention to this concern as it relates to ECDSA over a
curve that requires truncation to a non-multiple of 8 bits, and whether the
RS>> ECDSA is not what ietf dreams it up to be; it is how it is
specified in FIPS 186-4, BSI, ANSI X9.62, SECG (all at least 1 1/2
decades old specifications). These specifications are precise and
unambiguous. Those specifications use bit operations, not byte
operations and work also when the bit-size of the prime-order subgroup
of the curve is not a multiple of eight (e.g., when using binary curves
sect283k1). <<RS
behavior of the existing COSE ECDSA codepoints (which indicate specific
hash functions) has been fully specified in terms of the bits to select for
signature input.
RS>> Specifications that use externally defined algorithms (such as
ECDSA) should use those as is, not as one dreams those to be. This is
precisely where attention to detail ("fastidiousness" if you will)
matters. One should also read one's own specifications, instead of
simply making speculations about what is in there. <<RS
I do not recall seeing technical discussion to indicate
that this issue has been closed (but I am only human, and would welcome a
pointer to where such discussion has occurred).
RS>> Here is the pointer:
https://mailarchive.ietf.org/arch/msg/cose/oFTcLg_HviER-B7ciZGjPLR9xms/
<<RS
You say that you could write some text in parallel to the IESG review, but
this document is intended to be published on the IETF stream, and per RFC
8789 all documents on the IETF stream require IETF consensus. I think it
is clear from the ongoing discussions on the COSE WG list that further
effort is needed to determine the consensus position on these proposed IANA
RS>> It would help if people first read the RFC 8152 specification
before posting things on the mailing list, since the (very few) postings
I have seen often contravene what is actually in the document.
a) John Matton's email (Feb 16, 2021, 7.17am EST, see
https://mailarchive.ietf.org/arch/msg/cose/ITvErsVZ4jkzwJVjZ9sCuIT9EwM/)
I just noticed that RFC8152bis has the recommendation:
"Implementations SHOULD use a deterministic version of ECDSA such as the one defined
in [RFC6979]."
I don't think this is a good recommendation for IoT devices. In the last 5
years, i.e. after work on RFC 8152 started, there has been a large amount of
academic papers showing that purely deterministic ECC algorithms in accesable
IoT devices suffers from side-channel and fault injection attacks. For a list
of papers see e.g. Seciton 1
ofhttps://tools.ietf.org/html/draft-mattsson-cfrg-det-sigs-with-noise-02
Note RS: this inappropriate policy advice was already in RFC 8152 (and
is still proliferating within ietf), where one should note RFC 8152 was
published July 2017 (well after those attacks were known).
b) Ilari Liuusvara's email (Jan 28, 2021, 12.37pm EST: see
https://mailarchive.ietf.org/arch/msg/cose/4PIPilQY8a985StsFeft0No0-YI/)
Here, things get bit more complicated with Wei25519/Wei448.
These curves have h!=1 (unlike every past elliptic curve in COSE, which
all have h=1), so it makes sense to multiply at the end by h in order
to guard for attacks with small subgroups ("co-factor ECDH").
However, RFC8152 defers to RFC6090 for ECDH, and RFC6090 assumes that
h=1. However, RFC8152 also species the output encoding per curve, so
one could specify special output encoding that multiplies by h before
encoding in order to take h into account. This should give co-factor
ECDH on the new curves without defining any new algorithms.
Note RS: I asked Ilari offline a clarification of his suggestion, since I did not
understand how this would work (to which he did not respond). Two days later (Jan 30,
2021, 7.46am EST), Goran Selander and Ben Kaduk seem to embrace this approach (
https://mailarchive.ietf.org/arch/msg/cose/N7fMnbfhDCdE9ETNWaN3oBLQIXA/), where it is
absolutely unclear (to me) whether they even checked that the suggestion works. For the
record: I think it does not, since it confuses the "garbled up hack" confuses
the notion of bijective mapping and mappings that have more than one preimage. Even if
the approach would work, it would still have been a hack that is non-NIST/FIPS/BSI/ANSI
compliant behavior, since a change to the original co-factor ECDH protocol (NISTSP
800-56a, decade-old; 25+ years old in academic literature).
Both a) and b) are examples that illustrate that the group seems to have an
alarming lack of attention to detail and that it is hard to take email
responses that evidence lack of doing one's own homework on face value.
This perhaps also explains why it was easy for me to write the cms/pkix iana
section and that it is made extremely hard to reuse what is in RFC 8152, since
often lacking precision and attention to detail required for security
specifications.
<<RS
registrations, and thus that it is premature for the IESG to evaluate text
that is in flux and has undetermined consensus status.
RS>> It is hard to establish consensus if the "does this make technical
sense" lackmus test is taken out of the equation and one just count some
loose email traffic with no conclusion and proof of workability in sight.
<<RS
Thank you,
Ben
--
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
