Hi Hannes. Thanks for taking the time to review the specification.
draft-ietf-cose-cwt-claims-in-headers was created because multiple parties
independently realized that they had a need to use the equivalent of CWT
claims, such as issuer, subject, and confirmation, when they couldn't put them
in the payload. This can happen when the thing that's being signed and/or
encrypted can't be modified or isn't CBOR at all. For instance, if you're
signing PDF or JSON-LD or a bitmap image, you can't put the needed CWT claims
in the payload.
Lake invented a claim to use the CWT "cnf" claim in a header parameter. SCITT
was on the path to inventing the equivalent of issuer and subject claims as
header parameters when they realized that they could use claims-in-headers and
not have to create duplicative definitions for these existing claims. I know
of other use cases where COSE is being used to secure unmodifiable payloads.
All of these point to the value of having the claims-in-headers draft.
Yes, the draft currently explains claims-in-headers primarily in terms of the
JWT feature for duplicating claims. And it will be used that way with CWTs -
for instance, for making the issuer available in an unencrypted representation
when the CWT is encrypted. But the use cases where the claims *can't* be put
in the payload is where claims-in-headers really shine.
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?
See you soon!
-- Mike
From: Hannes Tschofenig <[email protected]>
Sent: Wednesday, November 1, 2023 10:31 AM
To: lgl island-resort.com <[email protected]>
Cc: [email protected]; [email protected];
[email protected]; [email protected]
Subject: Re: [COSE] Iotdir telechat review of
draft-ietf-cose-cwt-claims-in-headers-07
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
<[email protected]<mailto:[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]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/cose
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
