Inline:
On Tue, Oct 31, 2023 at 4:43 AM Hannes Tschofenig via Datatracker <noreply@xxxxxxxx> 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.
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.
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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
