Hi Carsten,
thanks for the detailed review feedback. A few remarks below:
Am 04.01.2024 um 15:40 schrieb Carsten Bormann:
A lot of people seem to like this document, so I apologize for having to rain
on this parade.
I'm not at all convinced this document is ready for WG adoption.
I guess it depends what your bar is. Bernard Aboba used to adopt
documents only when they are at the level of WGLC quality...
(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.
Regarding RFC 8725: RFC 8725 provides guidance for JWTs and this
document is offering guidance for JOSE/COSE but there is a relationship.
Therefore we should definitely point to to RFC 8725 and explain the
differences.
(2) For COSE, the one subject discussed leads to a new MUST on a header parameter that
defined in STD96 (kid, defined in RFC 9052, Section 3.1). I don't think a BCP can
redefine a parameter defined in a standards-track document. RFC 9052 is quite explicit
that »Applications MUST NOT assume that "kid" values are unique«:
kid: This header parameter identifies one piece of data that can be
used as input to find the needed cryptographic key. The value of
this header parameter can be matched against the "kid" member in a
COSE_Key structure. Other methods of key distribution can define
an equivalent field to be matched. Applications MUST NOT assume
that "kid" values are unique. There may be more than one key with
the same "kid" value, so all of the keys associated with this
"kid" may need to be checked. The internal structure of "kid"
values is not defined and cannot be relied on by applications.
Key identifier values are hints about which key to use. This is
not a security-critical field. For this reason, it can be placed
in the unprotected-header-parameters bucket.
I am happy with explaining what the consequences are. It is difficult to
enforcement mandatory uniqueness requirements written in RFCs in
libraries anyway. I am also open to change the type of the document from
BCP to a standards track document. I guess we can always do that when
the content is finally ready.
The next few items I will have to discuss with my co-authors to provide
a good proposal for resolving them:
(3) The rationale given in the draft for replacing the definition of this parameter with
what essentially is a new definition is rather wobbly. It seems that the intention is
not really to add security, but just to reduce the attack surface for attacks that
continue to be possible if the "guidance" of the document is heeded.
(4) The term "globally unique" is not defined. I don't think it actually means
anything in the specification as it is being used.
If the intention is to define a globally unique Key ID, please define a header parameter that has
the desired properties (e.g, "gukid", globally unique kid). For this, please define
"globally unique".
Or what we maybe should do here is define specific forms of the "kid" value
that do have some desirable uniqueness properties. Proponents of the approach of this
document can then recommend the use of one of these forms.
The recommendation you suggest below is good.
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.
kid-related:
2. try not to use identifiers for keys that suck (yes, need an operational
definition of what that means)
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?
I would add: store the algorithm alongside the key to prevent attackers
from changing the algorithm.
Ciao
Hannes
Grüße, Carsten
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
