Re: [COSE] Iotdir telechat review of draft-ietf-cose-cwt-claims-in-headers-07

[Michael Jones <[e-mail]>]

I created https://github.com/tplooker/draft-ietf-cose-cwt-claims-in-headers/pull/13 to describe the non-CBOR payload use case in response to Hannes’ IotDir review.  It also says that profiles define the semantics of the claims used, in response to further feedback from Carsten.

Reviews requested!

                                                       -- Mike

From: Michael Jones <[e-mail]>
Sent: Thursday, November 2, 2023 7:25 PM
To: lgl island-resort.com <[e-mail]>; Henk Birkholz <[e-mail]>
Cc: Hannes Tschofenig <[e-mail]>; Orie Steele <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: RE: [COSE] Iotdir telechat review of draft-ietf-cose-cwt-claims-in-headers-07

Thanks, Lawrence.  I agree with your assessment.

In my reply to this thread yesterday, I wrote:
I’d be glad to beef up the description of those motivating use cases in the draft.  I believe that would go a long way in the direction that you suggested: “At a minimum I expect the use cases to be better explained. Under what circumstances is it a good idea to even consider this approach as a developer?”  Do you agree with that direction?

Do people agree with describing these use cases?  If so, I’ll work with Tobias to produce an updated draft that we can publish shortly – once the submission window reopens.  It will further improve the specification.

                                                       Best wishes,
                                                       -- Mike

From: lgl island-resort.com <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, November 2, 2023 10:59 AM
To: Henk Birkholz <[e-mail]<mailto:[e-mail]>>
Cc: Hannes Tschofenig <[e-mail]<mailto:[e-mail]>>; Orie Steele <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [COSE] Iotdir telechat review of draft-ietf-cose-cwt-claims-in-headers-07

Call it what you want, but there’s three choices here:

1) Publish without warnings (which might be OK because there’s no warnings about COSE, JOSE and CMS protected headers).

2) Publish with warnings (and add errata for COSE and JOSE?)

3) Do not publish because of the security problems

Seems like Hannes wants 3). I wouldn’t go that far.

I’m fine with 1), but probably in the minority on such these days.

LL




On Nov 2, 2023, at 10:11 AM, Henk Birkholz <[e-mail]<mailto:[e-mail]>> wrote:

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/> <http://island-resort.com<http://island-resort.com/>> <[e-mail]<mailto:[e-mail]>> wrote:

   Hi Hannes,

   On Nov 1, 2023, at 10:30 AM, Hannes Tschofenig
   <[e-mail]<mailto:[e-mail]>> 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<https://transmute.industries/>>


_______________________________________________
COSE mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/cose
_______________________________________________
COSE mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/cose