I’ve had a look through this new draft and I have some comments and questions. Some of which are similar to comments I already raised [1], but haven’t been addressed.
Are we concerned about Holders and Issuers colluding? For example, now that claim names are blinded an Issuer can add the same claim multiple times with different, potentially contradictory, values and then the Holder can selectively release one disclosure to one Verifier and a completely different one to another Verifier. This seems problematic at least, that the “same” credential could be interpreted differently by different parties. A more sophisticated version of this “attack” illustrates the need for collision resistance in the hash function, not just preimage resistance as stated in the draft (and already raised by me in [1]). If the hash is not CR then a malicious Issuer can find colliding [salt, key, value] triplets that have the same hash value, give one to the Holder and then later claim that they actually signed the other one. (This is not just theoretical, similar attacks have been used to create fraudulent SSL certificates [2]). This also indicates that the security strength of the signature scheme is bounded by the collision resistance of the hash function - e.g. there’s little point using ES512 with SHA-256, for example. Probably the security considerations should suggest matching hash functions to signature algorithms. Furthermore, preimage resistance is not a sufficient property to ensure confidentiality of withheld claims. Preimage resistance holds if the attacker cannot recover the exact input that produced a given hash value, but it doesn’t preclude the attacker being able to recover partial information about that value. For example, consider the hash function H(x) = SHA-256(x) || x[x.len-10..x.len] (where || is concatenation). This hash function when applied to SD-JWT is preimage resistant (assuming the salt is strong), but leaks the last 10 bytes of the claim value. The appropriate security definition for SD-JWT is some form of cryptographic commitment scheme [3], with the associated security notions of hiding and binding. Honestly, I still think that this WG is not an appropriate venue for this kind of novel (in the OAuth world) cryptographic scheme and external review by experts would be helpful. All of this suggests that simply referring the the IANA hash function registry is not sufficient, as probably *most* of the entries there are not actually suitable for use in SD-JWT for one reason or another. Some other comments: The original JWT RFC [4] has this to say about the order of encryption and signatures: signatures over encrypted text are not considered valid in many jurisdictions. Presumably the same argument holds about signatures over blinded values? That should perhaps be noted at least. The draft repeatedly says that a symmetric signature algorithm (MAC) must not be used. Perhaps I’m missing something here, but why not? It doesn’t seem like it compromises any of the intended security properties. Use of a symmetric MAC may also limit the privacy impacts on users as it provides some measure of deniability (similar to that mentioned in section 12.1), as any Verifier in possession of the secret key could also have produced any claims that are subsequently leaked, allowing the user to deny that they were produced by the supposed Issuer. (This deniability property holds even without subsequent leaking of old signing keys). The security considerations about salt entropy should probably reference RFC 4086 (BCP 106) or something more up to date (maybe RFC 8937 too). I think section 11.8 about selectively disclosing contraints on the use of a SD-JWT is completely inadequate and will almost certainly lead to attacks. Requiring Verifiers to hard-wire the set of constraints they enforce is likely to be damaging to future evolution of the standard as new security constraints are added. It would seem especially problematic to allow selective disclosure of a “cnf” claim for example, and yet nothing forbids it and the history of JWT usage suggests that anything not forbidden will at some point happen (and even some things that are forbidden). I suggest establishing a registry of claims that are really usage constraints and forbidding issuers from allowing anything in that list to be selectively-disclosed. (There are perhaps some exceptions here, e.g. “aud” is a constraint in this sense but it probably _does_ make sense for it to be selectively disclosed, but only on a per-array-item basis: that way a Holder cannot remove the constraint entirely but can still hide other “recipients”). On a related note, section 11.6 says that to avoid this kind of attack, Verifiers MUST NOT take into account whether a Key Binding is present or not to decide whether to require Key Binding. This seems to preclude Verifiers that can handle different levels of access with different security requirements and is the sort of requirement that makes it near impossible to incrementally evolve tougher security requirements over time. It effectively becomes an all-or-nothing switch that will have the likely effect of making the use of Key Binding less attractive. Security hardening should be the easy path if we want to see it adopted. Best wishes, Neil [1]: https://mailarchive.ietf.org/arch/msg/oauth/NOPT1WNtvMvlygLaZH7YvLFVpKo/ [2]: https://www.cnet.com/news/privacy/web-browser-flaw-could-put-e-commerce-security-at-risk/ [3]: https://en.wikipedia.org/wiki/Commitment_scheme > On 23 Oct 2023, at 17:17, internet-dra...@ietf.org wrote: > > Internet-Draft draft-ietf-oauth-selective-disclosure-jwt-06.txt is now > available. It is a work item of the Web Authorization Protocol (OAUTH) WG of > the IETF. > > Title: Selective Disclosure for JWTs (SD-JWT) > Authors: Daniel Fett > Kristina Yasuda > Brian Campbell > Name: draft-ietf-oauth-selective-disclosure-jwt-06.txt > Pages: 90 > Dates: 2023-10-23 > > Abstract: > > This specification defines a mechanism for selective disclosure of > individual elements of a JSON object used as the payload of a JSON > Web Signature (JWS) structure. It encompasses various applications, > including but not limited to the selective disclosure of JSON Web > Token (JWT) claims. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-06.html > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-selective-disclosure-jwt-06 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
