No you are the right level of paranoid, but imo, attacking the wrong layer to resolve the issue.
I might conclude that OAUTH is unsafe based on your comment, not that JOSE / COSE architecture is unsafe.
The problem is one of layers. Security considerations apply to each layer.
OAUTH builds on JOSE, that means it takes as a given, all the problems that come from JOSE.
This was discussed on the JOSE list recently:
https://mailarchive.ietf.org/arch/msg/jose/TIvr2FPetPKk4Ma1QIf0gNdAAIs/
JOSE does not define a key discovery or token verification protocol, and per the thread above,
JOSE provides no guidance forbidding processing of untrusted data, prior to verification...
AFAIK, the same is true of COSE and CMS... so the issue you are reporting is one with OAUTH, not JOSE.
I might conclude that OAUTH is unsafe based on your comment, not that JOSE / COSE architecture is unsafe.
The problem is one of layers. Security considerations apply to each layer.
OAUTH builds on JOSE, that means it takes as a given, all the problems that come from JOSE.
This was discussed on the JOSE list recently:
https://mailarchive.ietf.org/arch/msg/jose/TIvr2FPetPKk4Ma1QIf0gNdAAIs/
JOSE does not define a key discovery or token verification protocol, and per the thread above,
JOSE provides no guidance forbidding processing of untrusted data, prior to verification...
AFAIK, the same is true of COSE and CMS... so the issue you are reporting is one with OAUTH, not JOSE.
I think it's fine for JOSE to say "be careful building protocols"... but there is a point of diminishing returns for an upstream supplier to imagine all the ways a downstream supplier could misuse their product... However, I am still supportive of providing best effort guidance regardless.
You've written a draft targeted at addressing this issue, but that's not a good reason to object to a simple draft that registers new header parameters.
OS
You've written a draft targeted at addressing this issue, but that's not a good reason to object to a simple draft that registers new header parameters.
OS
On Thu, Nov 2, 2023 at 10:14 AM Hannes Tschofenig <hannes.tschofenig@xxxxxxx> wrote:
Hi Orie,
just yesterday I learned about new OAuth security incident, see
https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts
In this attack, from my understanding, the problem was that access token verification was not done properly.
Am I really too paranoid?
Ciao
Hannes
Am 02.11.2023 um 15:18 schrieb Orie Steele:
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.
Therefore, these concerns should be handled independently, for example in guidance or BCP documents.
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
_______________________________________________ COSE mailing list COSE@xxxxxxxx https://www.ietf.org/mailman/listinfo/cose
ORIE STEELE
Chief Technology Officer
www.transmute.industries
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
