On Tue, Sep 17, 2024 at 11:11:43AM -0500, Orie Steele wrote: > JOSE and COSE go about this step differently... It's even more confusing > because in JOSE AEADs are mandatory, whereas in COSE they are not... > The objective of this step is to commit some protocol information, into the > encryption step... AEAD AAD is used where it can be... KDF context info can > also be used here: > > - > https://datatracker.ietf.org/doc/html/rfc9053#name-context-information-structu > > ... in hindsight, this is a layer violation that forces both JOSE and COSE > to maintain a separation between keys and algorithms... or if you want to > think of it another way... it's the binding between algorithms and keys in > both protocols.
The real problem is that there is no way to express class of compatible algorithms. Which might not be interchangeable in JOSE. In COSE, one can interconvert types, but this costs bytes and interop. > ... this is also the layer where we get "2 payloads", because in JOSE we > have both the protected header and the payload... and you can put protocol > parameters in either... Later this leads to JWT / CWT parameters in headers > and payloads. > > ... it's inherited from ASN.1 supposedly... maintaining this design pattern > is the "conservative approach", in that... it's doing what we have "always > done". Furthermore, it mixes COSE/JOSE and application headers. That kind of mixing reminds me of HTTP, which really mixes all sorts of stuff into headers. > ## Key Discovery > > In the simple case that there is only 1 supported ciphersuite and each > party only has 1 key, there is no need to communicate other information. > > If there are multiple keys, the key that is being encrypted too needs to be > identified, to avoid the recipient having to try all their keys. > > At this stage we would add the key identifier as a parameter to > the cborEnvelope or joseEnvelope. > > There is never a need to convey the algorithm or ciphersuite... because > they are always included in the key representation, so the key identifier > explicitly communicates them. This gets problematic if there are multiple recipients, which is supported in COSE/JOSE. > In the pull request for ML-DSA key representations, we constructed a new > key type for COSE and JOSE, called "algorithm key pair" : > > https://github.com/cose-wg/draft-ietf-cose-dilithium/pull/5/files > > The algorithm property is mandatory for this key type, and the thumbprint > is computed over it. In COSE/JOSE this only works for pure-only signatures. > ... some other comments > > The fork in the road happens in "Application Protocol Context > Separation"... this is where we see the AEAD differences and the context > info differences... > This is where we get protected header parameters... and where we first get > our chance to put "algorithm information" in a "header parameter"... > Because of the design of JOSE and COSE, we are forced to take the same path > through this step each time, and that is why we are always stuck handling > algorithm identifiers and keys as seperate things. > In JOSE "alg" is a mandatory header parameter... in COSE it is not... but > COSE ends up making it mandatory in a different way, and enabling not AEADs > at the same time. The key should specify what is the first thing it encounters. But COSE/JOSE usually has other steps as well, and alg does not have the correct granularity. > JOSE has alg none, which is also a problem at this layer of the design. ... And JOSE libraries usually don't handle it sanely (return invalid signature error). > The counter argument to "don't put algorithms in headers" is "never use an > algorithm which you do not trust" and "with a key it is not meant for"... > in code this means: > > - restricting keys to specific algorithms (even tho the specs do not > mandate this) > - comparing algorithms in header to algorithms in keys (even though they > are not required to be present in either) Restricting "oct" keys to given "alg" is a good idea (but don't use Direct Encryption: That always allows unsafe algorithms!). > I think time has shown that it would have been safer / simpler to just "not > put algorithm identifiers in headers". Safer maybe, but not simpler. > There is also the issue of bulk encryption / splitting key establishment > and content encryption up... both JOSE and COSE do this, and it leads to > "intermediate keys" and in JOSE, multiple algorithm identifiers in headers > ("alg" and "enc"). COSE also has multiple algorithm identifiers, but with all of those being "alg". > JOSE could have shuffled things around like COSE did and avoided "enc" all > together... or internalized things like HPKE does... but JOSE came first. JOSE essentially hardcodes having 2 layers. - JOSE "enc" acts like COSE layer0 "alg". - JOSE "alg" acts like COSE layer1 "alg". Whereas COSE allows 1 or more layers. That's what makes HPKE much easier in COSE: Unwanted layers can be dropped and uniform way to do CEK/KEK. > ... final thoughts > > If I could wave a magic wand, I would 100% make algorithms part of keys, > and make identifiers committing to keys, and handle the layering > differently. > Regardless of the era in which these protocols were constructed, we have a > responsibility to deprecate the parts of them that are problematic, and > offer upgrade paths where possible. That's easy with single-recipient, but gets very hard with multi- recpient. > For a recent example of this, see: > > https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-cek-hkdf-sha256-04#name-use-of-of-hkdf-with-sha-256 > > COSE needs a draft that conceptually accomplishes the same thing. That seems to have nothing to do with algorithms being part of keys. And isn't there individual I-D that would be pretty much the same thing for COSE? > New COSE work needs to account for attacks that were discovered after COSE > was constructed, it can't just say "we've always done it this way". Unfortunately "we've always done it this way" can get baked deep into code and be very painful to change. Or worse, get baked deep into COSE/ JOSE and be nigh-impossible to change. However, alternative approaches frequently exist. For example, draft-ietf-lamps-cms-cek-hkdf-sha256 very much needs to work around stuff baked deep into CMS. -Ilari _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
