Thanks for your time at the IETF meeting to discuss the comments and to work out text to address them.
I agree that the draft is ready now. Ciao Hannes From: COSE <[email protected]> On Behalf Of Michael Jones Sent: Freitag, 10. November 2023 17:05 To: Hannes Tschofenig <[email protected]>; Carsten Bormann <[email protected]> Cc: Orie Steele <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [COSE] Iotdir telechat review of draft-ietf-cose-cwt-claims-in-headers-07 Hi Hannes, -09 contains the use case and security considerations text we worked on together. Thanks for your quick work on this! Can you please update your IotDir review status from “Not Ready” to “Ready”? Thanks again! -- Mike From: Michael Jones <[email protected] <mailto:[email protected]> > Sent: Thursday, November 9, 2023 12:53 PM To: Hannes Tschofenig <[email protected] <mailto:[email protected]> >; Carsten Bormann <[email protected] <mailto:[email protected]> > Cc: Orie Steele <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> Subject: RE: [COSE] Iotdir telechat review of draft-ietf-cose-cwt-claims-in-headers-07 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 <[email protected] <mailto:[email protected]> > Sent: Thursday, November 2, 2023 7:25 PM To: lgl island-resort.com <[email protected] <mailto:[email protected]> >; Henk Birkholz <[email protected] <mailto:[email protected]> > Cc: Hannes Tschofenig <[email protected] <mailto:[email protected]> >; Orie Steele <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> 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 <[email protected] <mailto:[email protected]> > Sent: Thursday, November 2, 2023 10:59 AM To: Henk Birkholz <[email protected] <mailto:[email protected]> > Cc: Hannes Tschofenig <[email protected] <mailto:[email protected]> >; Orie Steele <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> 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 <[email protected] <mailto:[email protected]> > 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> 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 <http://island-resort.com/> island-resort.com < <http://island-resort.com/> http://island-resort.com> < <mailto:[email protected]> [email protected]> wrote: Hi Hannes, On Nov 1, 2023, at 10:30 AM, Hannes Tschofenig < <mailto:[email protected]> [email protected]> 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 <mailto:[email protected]> [email protected] <https://www.ietf.org/mailman/listinfo/cose> https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list <mailto:[email protected]> [email protected] <https://www.ietf.org/mailman/listinfo/cose> https://www.ietf.org/mailman/listinfo/cose
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
