Hi Hannes,
if your "stack of parsing things" encounters an unprotected CWT claims
set within a a well-defined COSE header parameter value, then interprets
that unprotected CWT claims set like ti is a well-defined CWT, then
somehow acquires semantics for that "CWT" that it found inside a COSE
envelope, then interprets them, and then acts as if it were the contents
of a stand-alone CWT with some semantics.... No - I would not call that
paranoia. But admittedly, I would not know what to call that.
Viele Grüße,
Henk
On 02.11.23 16:14, Hannes Tschofenig 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
On Thu, Nov 2, 2023 at 12:38 AM lgl island-resort.com
<http://island-resort.com> <lgl@xxxxxxxxxxxxxxxxx> wrote:
Hi Hannes,
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.
LL
--
ORIE STEELEChief Technology Officerwww.transmute.industries
<https://transmute.industries>
_______________________________________________
COSE mailing list
COSE@xxxxxxxx
https://www.ietf.org/mailman/listinfo/cose
_______________________________________________
COSE mailing list
COSE@xxxxxxxx
https://www.ietf.org/mailman/listinfo/cose
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
