As a more general matter, I think we are having difficulty here because we have a cryptographic abstraction that can be used in many different ways and different people are coming to the table with concerns at different levels of abstraction.
It is really easy to dismiss attacks as ‘irrelevant’ because they are not relevant in the context a thing is designed to be used. But of course a measure of success for a system is being used in unexpected ways. It is also easy to make a set of decisions that meet the stakeholders present in the room are fine with that don’t work for other stakeholders who approach things in different ways. Case in point is JOSE mandating AEAD encryption, that was fashionable at the time. I don’t think a platform should be in the business of telling applications which algorithms to use let alone which types of encryption. A platform spec like JOSE should be good for 30-50 years of service. While I am sure there will be plenty of AES systems around in 2050, I am equally certain that an application designer proposing a completely new system in 2050 might well choose an encryption algorithm that isn’t even defined yet as mandatory. There are many issues raised in deployment of ML-KEM and ML-DSA which require us to go back and ask if we did it right in previous systems. One of the meta level problems I think we have as a community is that we still have very limited experience of using digital signatures for non-repudiation. And a bigger problem is that while we are very hung ho about use of transport encryption, we don’t sign stuff as often as we should. Signing GIT commits remains the exception rather than the rule. On Wed, Sep 18, 2024 at 10:47 AM lgl island-resort.com < [email protected]> wrote: > > On Sep 17, 2024, at 1: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. > > > I’m open to other arrangements than the current draft, but would to > achieve these: > - Not use Context Info Structure. In particularly not require > implementors to read and understand NIST SP800-56. > - Be much more clear than the COSE RFCs are about the encryption > context(s) > - Address the AEAD downgrade attack > > > > 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. > > > I’m asking myself if this indicates a problem with PGP, CMS and lots of > other formats that we’ve been using for decades. > > LL > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
