I agree with much of what you wrote. Lets walk through an example of building an application layer protocol for HPKE to see where parameters show up, if we were designing from scratch and with 2020 hindsight.
## HPKE Crypto Layer recipientPublicKey, recipientPrivateKey = keyGen( ciphersuite ) contentCipherText, kemCipherText = encrypt(plaintext, recipientPublicKey) recoveredPlaintext = decrypt(contentCipherText, kemCipherText, recipientPrivateKey) HPKE has been built with the benefit of learning from ECDH-ES / KDFs / PartyU / PartyV. It internalizes a lot of things that we would have put in headers, previously. However, you still need to convey contentCipherText, kemCipherText... and handle errors that might be produced if kemCT is tampered with: https://datatracker.ietf.org/doc/html/rfc9180#base-crypto ## JOSE / COSE Application Protocol Layer At this point, you are ready to consider protocol specific context information, the purpose of this step is to ensure that sender and receiver agree they are using COSE, or JOSE... with the assumption they are already supporting HPKE. The first step is to construct a single message that contains both contentCipherText, kemCipherText ... it could use base64url and "." or cbor major types. After this step the information conveyed is cborEnvelope or joseEnvelope... not contentCipherText, kemCipherText. ## Application Protocol Context Separation Before encrypting or decrypting, sender and receiver need to agree to use a serialization and an hpke ciphersuite. Here you can add protocol specific context separation: - https://datatracker.ietf.org/doc/html/rfc9052#section-5.3 - https://datatracker.ietf.org/doc/html/rfc7516#section-3 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. ... 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". ## 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. 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. ... 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. JOSE has alg none, which is also a problem at this layer of the design. 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) I think time has shown that it would have been safer / simpler to just "not put algorithm identifiers in headers". 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"). JOSE could have shuffled things around like COSE did and avoided "enc" all together... or internalized things like HPKE does... but JOSE came first. ... 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. 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. 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". If you got this far, thanks for reading. OS On Tue, Sep 17, 2024 at 3:33 AM <[email protected]> wrote: > Hi all, > > > > When I presented an update on the COSE HPKE draft at the last IETF meeting > (see slides-120-cose-use-of-hpke-with-cose (ietf.org) > <https://www.ietf.org>), Sophie made an insightful remark that got me > rethinking the construction of the context information. She noted, "you > cannot trust the information in the headers", in response to my > presentation. This is particularly relevant because the current draft > suggests placing all context information into the header so it is included > in the authenticated data. > > > > Ideally, when a recipient processes the message, the first step involves > using the key ID to retrieve the key required to decrypt the payload (or > identify the key used by the key exchange mechanism to derive the content > encryption key). Best practices dictate that different keys should be used > for different purposes, meaning there should be a one-to-one relationship > between the key and the associated algorithm information. For instance, a > key designated as a KEK for AES-KW should not be used directly for content > encryption. > > > > This implies that the parties involved in the communication should avoid > including algorithm-related information in the message header. Instead, > this information should be retrieved based on the key identifier. Thus, > more than just the key ID and the key must be shared between the > communicating parties; key-related metadata must also be exchanged. > > > > If I understood Sophie correctly, the current approach of relying on > header-based context information is not useful. We should reconsider why > we are embedding all of this information in the header in the first place, > as it may actually weaken security. > > > > Ciao > Hannes > > > > [1] Interestingly, I had already advocated for using the key ID to select > all other parameters back in 2015. See [COSE] alg Header Parameter > (ietf.org) > <https://mailarchive.ietf.org/arch/msg/cose/Ybou-lGY5C2DwYlorI8wRwxlmN0/> > > > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
