Re: [COSE] (on ecdsa codepoints cose iana) Re: next steps for draft-ietf-lwig-curve-representations

[Rene Struik <[e-mail]>]

Hi Ben:

A friendly reminder of the reminder of the reminder. Is it really 
necessary (or fair, for that matter) that a simple technical disposition 
email exchange takes more than a half year, with me having to 
consistently pick up dropped balls?

Best regards, Rene

On 2021-08-06 12:21 p.m., Rene Struik wrote:
> Hi Ben:
>
> A friendly reminder: in your email of July 15th below you suggested 
> you still had to finalize the review of the OLD vs. NEW text for ECDSA 
> cose iana code points (that I suggested June 14, 2021). If you could 
> do so, that would be great, since it helps to get to badly needed 
> closure: this has been dangling for quite a while now.
>
> Best regards, Rene
>
> On 2021-07-15 12:25 a.m., Benjamin Kaduk wrote:
>> Hi Rene,
>>
>> Sorry to have dropped your earlier mail -- there's been enough going on
>> with family and time off that my inbox has been growing a bit faster 
>> than I
>> can process things, so I missed some things.
>>
>> The proposed NEW text regarding 'alg' generally looks good.  I would 
>> need
>> to check on the bit about setting the "crv" parameter as it appears 
>> in COSE
>> and JOSE, but the actual diff between OLD and NEW looks to be good 
>> changes.
>>
>> For the lack of precision in ES256 I don't have a clear answer just yet;
>> there seem to be a few options to consider, all of which have some 
>> reason
>> to be distasteful or procedurally challenging (e.g., pulling
>> rfc8152bis-algs out of the RFC Editor queue, doing a short document 
>> in COSE
>> to update the specification, having this document update the core COSE
>> specification, defining a new mostly-redundant codepoint).  It is very
>> useful to have the text in Appendix Q available as an example of what 
>> the
>> "more precise" definition would look like, even if it ends up 
>> appearing in
>> some other document rather than this one.
>>
>> You had also asked about ECDSA w/ SHAKE128.  I'm pretty ambivalent about
>> that -- while I can understand the desire to define both algorithms for
>> some kind of parity, it also seems quite defensible to wait to 
>> specify the
>> algorithm until there is an actual consumer ready.  It may be 
>> expedient to
>> keep things simple and not add unnecessary things at this stage.
>>
>> -Ben
>>
>> On Wed, Jul 14, 2021 at 02:04:26PM -0400, Rene Struik wrote:
>>> Hi Ben:
>>>
>>> Any feedback on my suggested disposition of your cose code point remark
>>> for ECDSA w/ SHAKE256? What about my note on lack of precision in ES256
>>> and suggested path to "fix" this? Please see my email of June 14th 
>>> below
>>> for details.
>>>
>>> Best regards, Rene
>>>
>>> On 2021-06-14 12:49 p.m., Rene Struik wrote:
>>>> Hi Ben:
>>>>
>>>> I do believe your suggestion to allocate a code point for ECDSA with
>>>> SHAKE256 (thereby, untie-ing this from the curve) is easy to
>>>> accommodate with the draft.
>>>>
>>>> This would come down to changing Section 12.3.2 as below (change of
>>>> Name and Description fields only, plus pointer to example):
>>>>
>>>> 12.3.2. COSE Algorithms Registration (1/2)
>>>> This section registers the following value in the IANA "COSE
>>>> Algorithms" registry [IANA.COSE.Algorithms].
>>>> Name: ECDSA with SHAKE256;
>>>> Value: TBD (Requested value: -48);
>>>> Description: ECDSA with SHAKE256;
>>>> Change Controller: IESG;
>>>> Reference: specified in Section 4.4 of this specification; for
>>>> encodings, see Section 10.2; for an example, see Appendix Q.3.3.
>>>>
>>>> and changing the last para of Section 10.2 as below (i.e., untieing
>>>> the curve from "alg" parameter [since "alg" now becomes ECDSA+SHAK256,
>>>> rather than ECDSA+SHAKE256+Wei448):
>>>>
>>>> OLD:
>>>> The encodings below specify the use of instantiations of ECDSA with
>>>> COSE (see Section 10.2.1) and JOSE (see Section 10.2.2), where the
>>>> encoding for a specific ECDSA instantiation (i.e., with a specific
>>>> short-Weierstrass curve and specific hash function) results by setting
>>>> the "crv" parameter to the unique name of the underlying curve in
>>>> question and the "alg" parameter to the unique name of the specific
>>>> signature scheme instantiation (e.g., "ECDSA25519" for the ECDSA
>>>> scheme defined in Section 4.3 and "ECDSA448" for the scheme defined in
>>>> Section 4.4). Note that, in this case, the "alg" name uniquely defines
>>>> the curve (and, thereby, implicitly the underlying "crv" parameter)
>>>> and the underlying hash function.
>>>>
>>>> NEW:
>>>> The encodings below specify the use of instantiations of ECDSA with
>>>> COSE (see Section 10.2.1) and JOSE (see Section 10.2.2), where the
>>>> encoding for a specific ECDSA instantiation (i.e., with a specific
>>>> short-Weierstrass curve and specific hash function) results by setting
>>>> the "crv" parameter to the unique name of the underlying curve in
>>>> question and the "alg" parameter to the unique name of the specific
>>>> signature scheme instantiation. For JOSE, this is realized by setting
>>>> the "alg" parameter to "ECDSA25519" for the ECDSA scheme defined in
>>>> Section 4.3 and to "ECDSA448" for the scheme defined in Section 4.4).
>>>> For COSE, this is realized by setting the "alg" parameter to "ES256"
>>>> (short-hand for "ECDSA with SHA-256") for the ECDSA scheme defined in
>>>> Section 4.3 and to "ECDSA with SHAKE256" for the scheme defined in
>>>> Section 4.4). Note that, in the case of JOSE, the "alg" name uniquely
>>>> defines the curve (and, thereby, implicitly the underlying "crv"
>>>> parameter) and the underlying hash function, while in the case of
>>>> COSE, the "alg" name uniquely defines the underlying hash function,
>>>> but not the underlying curve.
>>>>
>>>> I do think this would highlight the (somewhat confusing [to me])
>>>> differences between COSE and JOSE treatment of ECDSA in a concise 
>>>> manner.
>>>>
>>>> I think this would settle the ECDSA/SHAKE256/Wei448 code point for
>>>> COSE. Could you confirm?
>>>>
>>>> As to using ES256, the main issue I see is that the definition of
>>>> ECDSA in RFC 8152 is not precise enough. For the exact definition, I
>>>> included Appendix Q (which is compatible with RFC8152's definition in
>>>> the deployed cases of ES256, ES384, and ES512, so using the exact
>>>> definition does not hurt current deployments and helps future ones).
>>>> Putting some verbiage to that effect into the draft should illuminate
>>>> this and settle this. Does this work? {If not, one still would need a
>>>> code point for "ECDSA with SHA-256 exact definition-style"; if so, one
>>>> would not need this (currently in Section 12.2.2).}
>>>>
>>>> Last note: RFC8692 defines ECDSA w/ SHAKEs (including both ECDSA w/
>>>> SHAKE128 and ECDSA w/ SHAKE256). It would be easy to align COSE to
>>>> this, simply by adding the ECDSA w/ SHAKE128 code point (to the
>>>> already requested code point for ECDSA w/ SHAKE256). There should be
>>>> sufficiently many "small-size" code points left to do so (one can use
>>>> "-9" if the verdict of the above para is okay).
>>>>
>>>> I hope this helps, Rene
>>>>
>>>> Ref: [1] Email Ben Kaduk of April 29, 2021, 6.29pm EDT, Subject: next
>>>> steps for draft-ietf-lwig-curve-representations
>>>>
>>>> [2]
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-21 
>>>>
>>>>
>>>> [3] https://datatracker.ietf.org/doc/html/rfc8152
>>>>
>>>> [4] https://datatracker.ietf.org/doc/html/rfc8692
>>>>
>>>>
>>>> On 2021-04-29 6:53 p.m., Benjamin Kaduk wrote:
>>>>> Hi Rene,
>>>>>
>>>>> My apologies for the slow response -- Erik, Roman, and I were able 
>>>>> to get
>>>>> together to talk about this document last week but then I had to 
>>>>> take a
>>>>> couple days off, which interrupted my drafting of this note.
>>>>>
>>>>> It seems that there are a handful of mostly orthogonal axes along 
>>>>> which action
>>>>> is needed, so I will try to enumerate them separately.
>>>>>
>>>>> [1] Intended status of the document (Informational vs Proposed 
>>>>> Standard).
>>>>>
>>>>> Since, at its core, the point of this document is to provide 
>>>>> information about
>>>>> how you can use elliptic curve isogenies (and isomorphisms) to use 
>>>>> an ECC
>>>>> implementation that is generic within one family of curves to perform
>>>>> operations defined on a different family of curves, the 
>>>>> Informational status
>>>>> seems most appropriate.  My undersatnding is that the intended 
>>>>> status was
>>>>> changed to Proposed Standard in order to qualify for allocations 
>>>>> from a
>>>>> codepoint range in the IANA COSE registries that has a shorter 
>>>>> encoding.  At
>>>>> present, those IANA Considerations are not even in the document, 
>>>>> but even if
>>>>> we do want to have IANA registrations for those COSE codepoints 
>>>>> eventually, it
>>>>> is fairly straightforward to do to in a separate document as needed.
>>>>>
>>>>> Accordingly, assuming the WG chairs (on behalf of the WG) do not 
>>>>> object,
>>>>> please go back to the Informational status in the next version.
>>>>>
>>>>> [2] Describing the motivation for the document
>>>>>
>>>>> My understanding of the core purpose of this document is 
>>>>> summarized in the
>>>>> previous point -- to allow reuse of code that is "generic" (but 
>>>>> not fully
>>>>> generic ECC code) to make more algorithms accessible to that 
>>>>> implementation.
>>>>> In our discussions, it seemed that Sections 1 and 2 could be seen as
>>>>> subsections of a single "motivation" section, and that the document's
>>>>> accessibility would be improved by adding a few clarifying 
>>>>> sentences covering
>>>>> the importance/relevance of this type of strategy for lightweight
>>>>> implementation.  Please consider performing this type of 
>>>>> restructuring to
>>>>> improve the document.  I am willing to suggest specific edits if 
>>>>> desired
>>>>> (though probably not with a particularly fast turnaround time).
>>>>>
>>>>> [3] Key types
>>>>>
>>>>> The JOSE registration requests currently in the document (and the 
>>>>> COSE ones,
>>>>> when they were there) are doing something that is without 
>>>>> precedent, namely
>>>>> allowing the use of both "OKP" and "EC" ("EC2" in COSE) key types 
>>>>> (i.e.,
>>>>> representations) for a single curve.  All the curves defined in 
>>>>> RFC 7518 use
>>>>> "EC" and only "EC; likewise, all the curves defined in RFC 8037 
>>>>> use "OKP" and
>>>>> only "OKP".  RFC 8812 is the only other JOSE curve registration, 
>>>>> which uses
>>>>> kty "EC".  I think this deviation from precedent is something that 
>>>>> does not
>>>>> have a presumption of IETF consensus, and that the JOSE and COSE 
>>>>> communities
>>>>> should be consulted on whether diverging from precedent in this 
>>>>> way is the
>>>>> correct course of action.  I will initiate an email thread with 
>>>>> the COSE and
>>>>> JOSE WG lists (and am happy to put you on the CC list if desired) 
>>>>> to consider
>>>>> this question.  If you do believe that it is important to be able 
>>>>> to use both
>>>>> key types with these new curves, I implore you to specifically 
>>>>> discuss the
>>>>> topic in the IANA considerations and provide some explanation or 
>>>>> justification
>>>>> for why it is the right thing to do.  Such text would be a useful 
>>>>> input to the
>>>>> discussion I will initiate with the COSE/JOSE WG lists.
>>>>>
>>>>> [4] COSE Algorithm semantics
>>>>>
>>>>> I include this text only for completeness, even though it is 
>>>>> perhaps only a
>>>>> matter for the IANA Considerations that requested allocation from 
>>>>> COSE
>>>>> registries.  (On the other hand, the main body text still includes 
>>>>> treatment
>>>>> on the use of the new algorithms with COSE as well as JOSE, which 
>>>>> might
>>>>> suggest that COSE-related topics remain in scope.)
>>>>>
>>>>> One of the goals of the COSE work was to (in some sense) "avoid 
>>>>> repeating the
>>>>> mistakes of JOSE".  This led to, among other things, changing the 
>>>>> key type
>>>>> value for two-coordinate ECC points from "EC" to "EC2" (as 
>>>>> mentioned above),
>>>>> but it also led to a fundamental change in what a COSE Algorithm 
>>>>> indicates.
>>>>> Whereas a JOSE algorithm for ECC signature indicates all three of 
>>>>> signing
>>>>> algorithm, hash algorithm (if applicable), and curve, in COSE the 
>>>>> algorithm
>>>>> indicates only two of those three: the signing algorithm and hash 
>>>>> algorithm
>>>>> (if applicable).  COSE indiates the curve separately. (JOSE also 
>>>>> has an
>>>>> explicit curve parameter, and avoiding this type of redundancy and 
>>>>> risk of
>>>>> inconsistency was the motivation for making the change in COSE.)  
>>>>> There is one
>>>>> exception to this classification, as you know: the ES256K 
>>>>> algorithm.  That was
>>>>> a deliberate exception to the rule, made not for purposes of 
>>>>> restricting the
>>>>> signature algorithm but rather to restrict what the *curve* can be 
>>>>> used for.
>>>>>
>>>>> Because there is already a COSE codepoint for ECDSA using SHA256, 
>>>>> there is no
>>>>> need for a new "ECDSA25519" codepoint -- the existing ES256 
>>>>> codepoint with
>>>>> curve Wei25519 would be the appropriate combination. (There is not 
>>>>> a COSE
>>>>> codepoint for ECDSA using SHAKE256, so some new codepoint would be 
>>>>> needed for
>>>>> the intended Wei448 construction.)
>>>>>
>>>>> The situation for ECDH25519 and ECDH448 is somewhat, but not 
>>>>> entirely,
>>>>> analogous, due to the complications of requiring cofactor ECDH -- 
>>>>> RFC 8152,
>>>>> its "bis" version, and RFC 6090 as referenced therefrom do not 
>>>>> cover cofactor
>>>>> ECDH.  In my opinion the topic of how COSE should handle cofactor 
>>>>> ECDH is
>>>>> something that should be discussed in the COSE WG and a consensus 
>>>>> decision
>>>>> reached.  It may or may not be decided to use a new codepoint for 
>>>>> cofactor
>>>>> ECDH, and so I feel strongly that this document should not 
>>>>> allocate a new
>>>>> codepoint for cofactor ECDH.
>>>>>
>>>>> (Also, COSE ECDH algorithms using KDF specify whether they are for
>>>>> ephemeral-static or static-static, so potentially two new 
>>>>> codepoints would be
>>>>> needed for both variants.)
>>>>>
>>>>> [5] Crypto review
>>>>>
>>>>> I know that the -00 did receive positive review from the CFRG 
>>>>> crypto panel,
>>>>> but there have been some changes to the relevant text in the 
>>>>> ensuing versions
>>>>> (as well as a great deal of things moving around in the 
>>>>> document).  The ADs
>>>>> are going to request a new crypto-panel review to confirm the 
>>>>> positive
>>>>> assessment, but since there is potential for further changes to 
>>>>> the document
>>>>> in light of the other points, we plan to wait to request such a 
>>>>> review until
>>>>> it is clear that the document has stabilized again. According to 
>>>>> my notes the
>>>>> most important sections are currently (-20) 4.1, 4.2, and 4.4, and 
>>>>> at least
>>>>> appendices F, G, and I.
>>>>>
>>>>>
>>>>> In the interest of full disclosure, I do have a few other topics 
>>>>> that I still
>>>>> need to do some more work/investigation on in order to tell if 
>>>>> they are
>>>>> serious issues or not.  These include (but are not limited to):
>>>>>
>>>>> - whether it is harmful to the Internet community to mention 
>>>>> "X25519+" and
>>>>>     "X448+" as new things distinct from X25519/X448 (and thus, maybe
>>>>>     better/preferred) without discussion of whether/why they are 
>>>>> better.  There is
>>>>>     harm to interoperability in specifying new algorithms just 
>>>>> because we can,
>>>>>     and I have seen indications (though perhaps not strong 
>>>>> evidence) that IETF
>>>>>     consensus is to only define new algorithms when there is a 
>>>>> clear need or
>>>>>     benefit from them.  My current inclination is to suggest to 
>>>>> remove
>>>>>     discussion of the "plus" variants since they currently seem 
>>>>> under-motivated,
>>>>>     though of course my opinion may change as I get more information.
>>>>>     (Similar considerations may apply to Wei25519.2 and 
>>>>> Wei25519.-3., etc.)
>>>>>
>>>>> - the specifics of ECDSA+SHA256 on Wei25519.  This is related to a 
>>>>> point made
>>>>>     by Ilari but I am not sure that we ever came to clear 
>>>>> agreement as to what
>>>>>     was in quesiton (let alone the answer).  The premise here is 
>>>>> that for the
>>>>>     existing ECDSA schemes/curves (P-256+SHA256, P-384+SHA384, 
>>>>> P-521+SHA512),
>>>>>     the range of the hash function is very close to the domain of 
>>>>> input for the
>>>>>     signing function (that is, the size of the prime underlying 
>>>>> the field over
>>>>>     which the curve is defined).  In particular, one of the ECDSA 
>>>>> references I
>>>>>     read by following reference chains from this document (sadly, 
>>>>> I did not note
>>>>>     which one) clearly states that the pretreatment of the hash 
>>>>> function output
>>>>>     prior to doing the curve arithmetic for signing involves 
>>>>> subtracting zero or
>>>>>     one multiple of the prime.  However, subtracting one copy of 
>>>>> 2^255-19 from
>>>>>     the "maximum output" of SHA-256 (i.e., 2^256-1) produces a 
>>>>> value that is
>>>>>     still outside of [0, 2^255-19), and so the referenced ECDSA 
>>>>> procedures are
>>>>>     not applicable for the combination of SHA-256 and Wei25519.  
>>>>> Given your
>>>>>     detailed treatment of byte- and bit-encoding, I expect that 
>>>>> you have given a
>>>>>     precise specification of what you expect to happen in this case.
>>>>>     Unfortunately, I think it is clearly out of charter for LWIG 
>>>>> (and arguably a
>>>>>     bad idea for the IETF itself, vs CFRG or NIST) to define new 
>>>>> ECDSA procedures
>>>>>     outside of what NIST has already specified.  Ideally there 
>>>>> would be a NIST
>>>>>     reference we could point to for this class of scenario; if 
>>>>> there is not one
>>>>>     already then my preference would be to ask NIST to produce some
>>>>>     clarification (there are a few NIST staff who participate in 
>>>>> the IETF).
>>>>>
>>>>> - the extent to which normative requirements from other documents are
>>>>>     duplicated in normative language in this document. Generally, 
>>>>> we try to
>>>>>     only have one authoritative source of any given normative 
>>>>> requirement, so
>>>>>     that it's clear what to do if there is any inadvertent 
>>>>> conflict between the
>>>>>     specifications.
>>>>>
>>>>> Thank you again for your efforts so far on this document, and my 
>>>>> apologies
>>>>> that we have not been very effective at helping you to understand 
>>>>> the expected
>>>>> procedures for a successful IETF-consensus RFC.
>>>>>
>>>>> -Ben
>>>>
>>>> -- 
>>>> email:[e-mail]  | Skype: rstruik
>>>> cell: [phone] | US: [phone]
>>>
>>> -- 
>>> email: [e-mail] | Skype: rstruik
>>> cell: [phone] | US: [phone]
>>>
>

-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]