Re: [COSE] draft-prorock-cose-post-quantum-signatures [Was: Re: Call for COSE Agenda Items for IETF 113 in Vienna]

[Rafael Misoczki <[e-mail]>]

I'm not quite familiar with kty's and OKP's yet (sorry, I hope to ramp up
soon) but from a pure crypto perspective, here are my two cents:

History has shown that anytime we left room for ambiguity in terms of the
primitive being used, we saw some sort of downgrade attacks in the wild.
See for example this attack
<https://www.youtube.com/watch?v=CiH6iqjWpt8&t=1428s> where AES-GCM is
replaced by the weaker AES-CBC, thus being exploited as an efficient
padding oracle.

For PQC, things are even trickier because most of them employ several
cryptographic building blocks. The choice for these building blocks has
critical security implications, so I won't consider them "equivalent".  For
example, SPHINCS+ using SHA256 or the more efficient Haraka are secure but
I won't be so sure if some other (second pre-image vulnerable) hash
function is plugged in.

Again, I'm not very familiar with all the nuances for the kty's design but
being as specific as possible may have some security benefits.




On Thu, Mar 10, 2022 at 1:00 PM Ilari Liusvaara <[e-mail]>
wrote:

> On Thu, Mar 10, 2022 at 04:56:55PM +0100, Anders Rundgren wrote:
> > Hi Orie,
> >
> > TL;DR
> >
> > This is my interpretation of how things presumably were intended to
> > work:
> >
> > Each "kty" represents a family of related key algorithms.
>
> No, each "kty" represents a key format. Each key format may or may not
> have multiple key types.
>
> For example, OKP is the key format with octet string private and public
> keys. It explicitly has nothing to more to do with elliptic curves than
> that initial key types all happened to be based on elliptic cuves.
>
> > Each signature "alg" represents a specific signature algorithm that
> > is compatible with exactly one "kty" family but not necessarily with
> > all of its members.  For ECDH which is polymorphic things gets a
> > little bit more fuzzy since it involves multiple "kty" families.
>
> Each alg is compatible with key types it is compatible with. That might
> include some key types of some key format (happens especially with OKP)
> or it might include entiere key formats (happens especially with EC2),
> or both at once.
>
> That might turn out to be bit problematic if, e.g., some joker defines
> some coordinate-swapped Edwards curve as EC2. Those things work just
> fine for ECDH. Attempting to perform ECDSA technically works, but breaks
> ECDSA specification.
>
> > Since "kty" is a top-level item you should (IMO...) be free to define
> > within reason :) whatever sub-level items that matches the algorithm
> > specification.  The bottom line is that it must be easy to figure out
> > which specific key- and signature-algorithms that were used,
> > preferably supporting table-driven designs as well.
>
> It goes the other way around: Once one has a new key type, one goes to
> see if it has existing key format, or if one should define a new key
> format for it.
>
> > However, the existing "kty" definitions should (for not breaking
> > existing software) be regarded as frozen even if EC keys indeed can
> > be used both for ECDH and ECDSA (but the use-cases for that are few
> > if any).
>
> Not being able to introduce new key types would for example imply that
> new elliptic curves can not be added.
>
> > If there are strong arguments for not using the same key with multiple
> > signature algorithms (assuming it is actually technically feasible as
> > well), the most robust solution would be to define signature and key
> > algorithms as pairs using the same identifier, but not under the same
> > label since "alg" already is reserved for use in "kty"s.  You could
> > also just say that "alg" in a "kty" is RECOMMENDED.  A problem here
> > is that this scheme does not necessarily work at the crypto API level
> > and then it becomes useless.  If this problem is for real, I would
> > talk to the algorithms designers to get their view on this as well.
> > This is obviously history in the making :)
>
> In general,  using the same key with multiple signature algoritihms is
> not cryptographically kosher. In fact, RSA-PKCS#1v1.5 is one of the rare
> exceptions (it has encoded message level indication of hash algorithm
> used).
>
> It depends on algorithm if trying to use mismatching key and algorithm
> is guranteed to blow up as implementation is faced trying to do the
> impossible (e.g., trying to mismatch dilithium2 and dilithium3),  or if
> it is just omittable implementation checks that prevent some
> key/algorithm pair from working (e.g. trying to mismatch ES384 and
> P-256 curve).
>
>
> However, there is no "key says what alg this actually is" alg value in
> COSE and JOSE. However, in current HTTP signatures work, there is such
> value (omitted alg means exactly that).
>
>
>
> -Ilari
>
> _______________________________________________
> COSE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cose
>