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
<[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.
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
[email protected]
https://www.ietf.org/mailman/listinfo/cose
