On Thu, Jan 04, 2024 at 05:15:08PM +0100, Hannes Tschofenig wrote:
> Hi Carsten,
>
>
> thanks for the detailed review feedback. A few remarks below:
>
>
> Am 04.01.2024 um 15:40 schrieb Carsten Bormann:
> >
> > (1) I don't understand the scope of this effort. The document is
> titled "Guidance for COSE and JOSE Protocol Designers and
> Implementers", but it actually only discusses one single subject. Is
> the document meant to stick with its current actual scope, or is the
> intention to cover what it promised by the title and abstract? It
> doesn’t even mention RFC 8725!
>
> The document has to start somewhere. During the last meeting others have
> raised further issues and in the LAMPS meeting the topic of GCM-CCM
> downgrade showed up as well.
Yes, the intention is to expand the scope. There already have been some
proposals on topics to cover, and I think there will be even more.
And on GCM-CCM downgrade, discussing the mitigations is certainly in
scope, but is the actual mechanism for fixing that issue?
> > But what this document really tries to do has little to do with
> > "kid", but can be summarized by a list of recommendations an
> > expression of which I'll steal from an off-list discussion:
> >
> > 1. try not to deserialize untrusted data needlessly (reducing attack
> > surface, not actually increasing security) — this is not just about
> > kid.
Especially evil is having the same data duplicated where one copy can
wind up being used in authentication and the other post-authentication.
Or mixing up authenticated and unauthenticated data, where
unauthenticated data can end up being treated as authenticated.
> > kid-related:
> > 2. try not to use identifiers for keys that suck (yes, need an
> > operational definition of what that means)
My operational definition for identifiers not sucking would be that
no system observes two different trusted keys with the same
identifier (that is, key identifiers may be treated as globally
unique).
Certainly no things like having e.g. RSA and ECDSA keys with the
same key id (I have heard rumors that some do that).
> > 3. you are still responsible for establishing the actual
> > authorization properties of the key ("trusting" it) before using it
> > to verify / decrypt...
> > -- but did you read all the warnings about how headers can be
> > misleading, and maybe you are holding the wrong key?
One way to screw this is not checking that the key belongs to the
correct issuer.
For systems where multiple issuers are expected, maybe it would better
to have overlapping key identifiers between issuers (get it right or it
will not work)?
> I would add: store the algorithm alongside the key to prevent
> attackers from changing the algorithm.
Only for symmetric keys, for that to be problem with asymmetric keys
requires a major flaw.
-Ilari
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
