I agree with both Carsten and Hannes. I see the document as having the scope to attempt to address the following:
1. acknowledging the security issues associated with optionality, even if optionality remains something that needs to be retained ( you are allowed to decode and validate payloads and headers, but you should avoid requirements that increase the attack surface, some choices of kid are better than others, regardless of what you use keys or identifiers for, etc... )... essentially explaining what defense in depth means for implementations of COSE/JOSE... not changing requirements, warning about the implications of covering them naively. 2. addressing drift between key identifiers, algorithms and security best practices (kid / alg mandatory / optional) in both keys and messages in both JOSE and COSE... There have been threads on both lists that could have been shortened with better references. 3. AFAIK, there is no CWT BCP, like JWT BCP ( RFC 8725 ) ... this document will either contain the prototype of that, or we should make it clear this is not meant to give guidance on token formats, only envelopes... perhaps that should be sorted out before adoption. I'd recommend citing and commenting on related drafts such as: - https://datatracker.ietf.org/doc/draft-jones-jose-fully-specified-algorithms/ - https://datatracker.ietf.org/doc/draft-ietf-cose-typ-header-parameter/ - https://datatracker.ietf.org/doc/draft-fossati-cose-profiles/ - https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes/ ( related to safe processing of content types that contain multiple suffixes ) In short I see a lot of valuable work to be done here, even without changing this from a BCP to something with more teeth. OS On Thu, Jan 4, 2024 at 10:15 AM Hannes Tschofenig <hannes.tschofenig= [email protected]> wrote: > 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 [email protected]https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
