Inline: On Tue, Oct 31, 2023 at 4:43 AM Hannes Tschofenig via Datatracker < [email protected]> wrote:
> Reviewer: Hannes Tschofenig > Review result: Not Ready > > Upfront I have to say I am a bit fan of the work the authors, Mike and > Tobias, > are doing in general. This document, however, does not meet my > expectations of > what they have published in the past. > > I am sorry to say it but the entire document is based on flawed > assumptions. > There is a good reason to put meta-data for signing and encryption into a > header while the actual payload, to which the security protection is > applied > to, is separated into the body. > > Where is the trend suddently coming from to put payload content into the > header, or (in related work) to place content that should be in the header > into > the payload? > > There are two arguments given in the introduction for why there is a need > to > copy content from the payload into the header: > > 1. This feature is also available for JWTs, and > 2. The payload may be encrypted and hence the recipient first has to > decrypt it > to see the plaintext value. > > Ad (1): It is not a good argument for me to also include this feature in > CWTs. > I would even drop the feature in JWTs. > > Ad (2): When content is encrypted then the idea is that sender would like > to > hide it from intermediaries and to only make it accessible to the > recipient. > Copying the plaintext values subsequently into the header isn't a great > idea. > Is this a way to apply encryption only to some values rather than others? > > Why cannot we demand from applications that use CWTs and JWTs that they > perform > the security processing first and then look at the payload for whatever > they > need? We could recommend this, but it would still require deserializing untrusted input to process the header, and in the case you are upgrading a protocol from JWT to CWT that uses the payload, I'm not sure it's safer to change the protocol than it would be to deserialize both the header and the payload as untrusted data. > Why do we have to replicate content for faster and more convenient > processing? > We don't, during WGLC I asked these questions: https://mailarchive.ietf.org/arch/msg/cose/-1dBxMtxAXhVZr6bIBQA3CXhnJI/ https://mailarchive.ietf.org/arch/msg/cose/LOxrLJwaqtFKT7kdZW5kVadkze8/ This led to the changes allowing these parameters to be present in the protected header, for payloads that are not CBOR maps. I think this is an excellent improvement, over how this was handled in JOSE. > > What is also not said in the document is that copying otherwise protected > content into the header introduces security vulnerabilities because > developers > will make security-related decisions BEFORE they process signatures, MACs > or > the encrypted payloads. Will this happen? Of course, it will. Please have a > look at > https://datatracker.ietf.org/doc/draft-tschofenig-jose-cose-guidance/. > I think these documents are trying to do very different things. I support separating guidance on safe use of registered claim names, from the ability to use registered claim names. I think the JWT BCP is another good example of providing guidance in a separate document. It calls out some issues with processing untrusted data that is in the protected header: https://datatracker.ietf.org/doc/html/rfc8725#name-do-not-trust-received-claim > Even on a smaller scale (with the key id) this already creates problems for > developers of COSE / JOSE libraries because the layers get combined and > important security decisions are outsourced to the developer. We know that > developers, who use these libraries, are unable to make good security > decisions. > I would say that they perhaps lack unified guidance, and part of the reason is that JOSE and COSE are building blocks for many different protocols, not just OAUTH related ones... COSE, and the JSON serialization of JOSE offers an unprotected header, it would be impossible to cover all the ways a protocol could misuse this, but it still seems worth commenting on in a guidance document. > > While the draft content is quite simple - almost innocent looking (namely > just > mapping the claims registry into the header parameter space), I fear the > solution just covers up bad design choices made by some applications using > CWTs > and JWTs. > I support your fear, but making the draft more complicated is not a good solution. Instead I think the draft should remain simple, and longer form guidance should be provided similar to the JWT BCP and the draft you are working on. > > 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? > I'm not sure the draft needs to address specific use cases, especially since doing so would likely require addressing all the other security considerations that come with the use cases. For example, encrypted CWTs for authentication, vs detached payload signatures for signing arbitrary content. 2 use cases with very different security considerations, both would be better addressed in a guidance document. > I know that most developers don't read RFCs - they look at libraries and > examples. Hence, we have to talk to developers of libraries to find out if > they > are able to write their libraries such that they can be safely used. I don't think this draft changes anything for library implementers. kid is still a top level element, and is still untrusted data. Other header parameters are still top allowed via reserved for private use, and are still untrusted data. > What is > the value of libraries written in language like Rust or F* when the > developer > can, with a small mistake, shoot themselves into the foot? > I agree with the concern, but it seems to apply to COSE and JOSE as a whole, not specific public claim names. The most significant of these issues is with `kid`, which is a pre-existing public claim name. Still I think better guidance can be provided on processing JOSE and COSE envelopes as safely as possible. -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
