Hi Laurence,
from your response below I understand that you are not sure
either about the use cases. We both guess what those could be. We
both don't know whether the use of claims in JWTs were a big
success. You also agree with me that information in the protected
header is often processed without prior security verification.
The difference in our conclusions is the judgement about how developers get away without making mistakes.
Ciao
Hannes
Am 01.11.2023 um 18:17 schrieb lgl
island-resort.com:
I don’t know of a critical need for claims-in-headers, but it seems like useful and I see little harm in it. Really like how simple and to the point the document is. More comments below:
On Oct 31, 2023, at 2: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.
If use in JWT was a success, then it is probably a good argument in favor. Personally, I don’t know if it was a success in JWT or not.
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?
I can think of uses in EAT where some claims need privacy and others don’t. Device ID (UEID) and GPS location might need privacy. The eat_profile does not need privacy and you might want to have a pre-processor dispatch to different full EAT processors. The OEM ID is probably also something that doesn’t need privacy and possibly something you might want to dispatch to specific attestation verifiers operated by specific OEMs.
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? Why do we have to replicate content for faster and more convenient
processing?
The best I can come up with is that the processing of the full CWT/JWT is done in a separate high security domain. The claims-in-headers are used for dispatch, pre-processing, early error detection or such outside of the high-security domain. Maybe the cost of decryption is high in some constrained devices or some very high volume uses and you want to be sure you’ve got the right CWT before decrypting it.
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/.
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.
The protected headers in COSE, JOSE, CMS and other are often processed before they are verified. In particular the algorithm ID has to be, because it tells you how to check the protected headers.
You could kind of say that standard protected headers are more dangerous than claims-in-headers because they are labeled as protected, yet they are not validated until the content is validated. There’s no warning about this in RFC 9052. Probably the documentation for COSE libraries doesn’t say “do NOT trust protected headers until AFTER the content is validated”.
From a security view, claims-in-headers seems near equivalent to COSE protected headers. If we write warnings about a security issue here, we maybe also file errata against 9052 with the same warnings for protected headers.
(It also seems redundant to put claims-in-headers in the protected headers bucket. The protection is redundant and it makes protected headers bigger which makes Enc_structure bigger.)
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
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 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. 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?
Personally, I tend to trust implementors a lot more than most folks here do. Well not actually. It’s more that I think we can only anticipate about half the the security issues they face in their real end-end system so they need to find the security smarts somewhere no matter what.
LL
_______________________________________________ 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
