Everything is a security issue if you are paranoid enough.
Could a developer decide not to verify after decoding a header? Absolutely.
W3C Verifiable Credentials secured with "Data Integrity Proofs" show you unverified data by default.
Should future protocols give guidance to minimize the processing of untrusted data? Yes ( and I would argue without exception ).
Do we need to declare protocols unsafe, that do "heavy processing" of untrusted data up front, to discover keys, or other hints that aid with verification?
I don't think so, but I have spoken to engineers / standards people from other communities and some of them think the answer to this question should be "yes".
Pointing out that lots of people do this / W3C / OAUTH / OIDC does it, etc... does not counter their argument.
If anything, knowing that a weakness exists, and is widely deployed, encourages us to consider it a ripe target for attackers.
We should expect damage from attacks on code that processes untrusted data to be higher than attacks that succeed after verification / decryption.
I don't think JOSE / COSE experts should dismiss perceived weaknesses... and it's my understanding that this is a common perceived weakness of JOSE and COSE.
That being said, it's not something this particular document should be addressing in any substantial way.
It's a preexisting condition, one that's severity is disputed.
We've got examples of this principle being violated in different ways.
What W3C Verifiable Credentials do is several orders of magnitude worse than what OIDC does.
... it depends on what kind of processing ... any processing of untrusted data, creates a slippery slope.
We are talking about general guidance here... It applies to all COSE and JOSE, not just this draft.
Could a developer decide not to verify after decoding a header? Absolutely.
W3C Verifiable Credentials secured with "Data Integrity Proofs" show you unverified data by default.
Should future protocols give guidance to minimize the processing of untrusted data? Yes ( and I would argue without exception ).
Do we need to declare protocols unsafe, that do "heavy processing" of untrusted data up front, to discover keys, or other hints that aid with verification?
I don't think so, but I have spoken to engineers / standards people from other communities and some of them think the answer to this question should be "yes".
Pointing out that lots of people do this / W3C / OAUTH / OIDC does it, etc... does not counter their argument.
If anything, knowing that a weakness exists, and is widely deployed, encourages us to consider it a ripe target for attackers.
We should expect damage from attacks on code that processes untrusted data to be higher than attacks that succeed after verification / decryption.
I don't think JOSE / COSE experts should dismiss perceived weaknesses... and it's my understanding that this is a common perceived weakness of JOSE and COSE.
That being said, it's not something this particular document should be addressing in any substantial way.
It's a preexisting condition, one that's severity is disputed.
We've got examples of this principle being violated in different ways.
What W3C Verifiable Credentials do is several orders of magnitude worse than what OIDC does.
... it depends on what kind of processing ... any processing of untrusted data, creates a slippery slope.
We are talking about general guidance here... It applies to all COSE and JOSE, not just this draft.
Therefore, these concerns should be handled independently, for example in guidance or BCP documents.
All this to say, I agree with Laurence.
OS
All this to say, I agree with Laurence.
OS
Hi Hannes,
LL
On Nov 1, 2023, at 10:30 AM, Hannes Tschofenig <hannes.tschofenig@xxxxxxx> wrote:You also agree with me that information in the protected header is often processed without prior security verification.
I’m not sure we’re thinking the same here.
I think there is no problem that calims-in-headers might be processed without verification.
I think that because we process protected headers/parameters in CMS, COSE and JOSE without verification.
If it’s not a security issue for CMS, COSE and JOSE, it’s not a security issue for claims-in-headers. CMS in particular goes back decades.
ORIE STEELE
Chief Technology Officer
www.transmute.industries
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
