Re: [Lwip] Magnus Westerlund's Discuss on draft-ietf-lwig-curve-representations-19: (with DISCUSS)

[Rene Struik <[e-mail]>]

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: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]