Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

[Neil Madden <[e-mail]>]

Hi Brian,

Apologies for the late reply. I *think* we’re closing in on agreement here. Comments and some wording suggestions inline below.

> On 27 Oct 2023, at 00:26, Brian Campbell <[e-mail]> wrote:
> 
> Thanks Neil!  Appreciate the productive discussion. Some more responses below (while also attempting to snip out and declutter the message).
> 
> On Thu, Oct 26, 2023 at 7:03 AM Neil Madden <[e-mail] <mailto:[e-mail]>> wrote:
>> On 25 Oct 2023, at 22:00, Brian Campbell <[e-mail] <mailto:[e-mail]>> wrote:
> 
> <snip> <snip>
>>> 
>>> The draft currently says that second-preimage resistance is needed, which prevents a malicious Holder from finding a different Disclosure value that results in a digest that's the same as one in the signed credential. Protecting against a malicious user effectively forging or modifying disclosed claim names/values is the security objective. Second-preimage resistance is not as strong as collision resistance but I believe is correct and sufficient for the context of use. And a malicious Issuer isn't something that's in scope and could do all kinds of other bad things. This is the section of the security considerations with that: 
>>> https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-06.html#section-11.5
>> 
>> Ok, that is a fair enough stance. Without requiring collision resistance though it does make SD-JWT a slightly weird signature scheme, in that the issuer is not actually committed to the contents of the token like they would be for a normal signed JWT. That is a surprising property. For example, if you store SD-JWTs for audit trail purposes (as some people do for normal JWTs), the contents are potentially repudiable. Like you say, if you trust the issuer then maybe that is fine, but it’s a sharp edge that maybe it would be better to remove? Given that pretty much any hash function that is likely to be used with SD-JWT will almost certainly be CR anyway. 
> 
> 
> As a compromise of sorts - would you be willing to propose some additional text to go in section 11.5 that (maybe strongly) recommends the hash function be collision resistant?

How about the following?

—
To ensure privacy of claims that are not being selectively disclosed in a given presentation, the hash function MUST ensure that it is infeasible to calculate the salt and claim name and value (or any portion thereof) that results in a particular digest. This implies the hash function MUST be preimage resistant, but should also not allow an observer to infer any partial information about the undisclosed content. In the terminology of cryptographic commitment schemes, the hash function MUST be computationally hiding.

The hash function MUST be second-preimage resistant. For any salt and claim value pair, it is infeasible to find a different salt and claim value pair that result in the same digest.

The hash function SHOULD also be collision resistant. Although not essential to the anticipated uses of SD-JWT, without collision resistance an Issuer may be able to find multiple disclosures that have the same hash value. The signature over the SD-JWT would not then commit the Issuer to the contents of the JWT, which is surprising. Where this is a concern, the collision resistance of the hash function SHOULD match the collision resistance of the hash function used by the signature scheme. For example, use of the ES512 signature algorithm would require a disclosure hash function with at least 256-bit collision resistance, such as SHA-512.
—

(I’d like to add an informational reference defining these terms, but I can’t find a good one - even the NIST/FIPS standards seem to just take terms like “collision resistance” for granted, so maybe we can too?)

> 
> I'm envisioning the resultant 11.5 section saying that the hash function MUST be second-preimage resistant and fully irreversible (as it does/will now with slightly updated wording discussed below) but then also goes on to say that it SHOULD just be collision resistant. I can come up with some text recommending CR too but maybe not with the rationale/explanation as you could. 
> 
>  
> <snip><snip> 
>>> Preimage resistance maybe isn’t the term to use there. It’s used in that section-11.5 <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-06.html#section-11.5> along with some text that says that it needs to be “infeasible to calculate the salt and claim value that result in a particular digest”.  We are trying to say that the hash has to have the property that it can’t be reversed (or even partially reversed, to your point). There’s probably a better way to state that the hash function has to be not at all reversible. Can you perhaps suggest some text? Or could we just replace “preimage resistant” with “irreversible” in that text in 11.5? And maybe qualify that text a bit more too with something like “infeasible to calculate the salt and claim value (or any portion thereof) that results in a particular digest”.
>> 
>> That latter text seems a pretty good start to me. Part of the terminology problem I think is that SD-JWT is couched in terms of signatures but actually its primary security goal is confidentiality.
> 
> I'd push back a bit on that and argue that the primary security goal is twofold and, as https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-06.html#section-11 attempts to articulate, is about enabling confidentiality of selectively disclosable content and ensuring the integrity (as issued) thereof. There may still be some terminology difficulties :) But the primary security goal is not just about confidentiality.
> 
>  
>> As I said, I think the correct formal security notions come from the work on commitment schemes, which are “binding” and “hiding”. The hiding property is what you want here - it basically says that it’s infeasible for an attacker to learn anything about the message from the hash that they couldn’t already infer without the hash. 
>> 
>> The binding property is maybe too strong if we trust the issuer - it would require collision-resistance as I’ve said. There is a paper (https://eprint.iacr.org/2017/664) which distinguishes between “sender-binding” and “receiver-binding”, which sounds similar to what you want to express: trusted issuer, potentially untrusted holder/verifiers. However, I think the receiver binding notion is still too strong and would also require collision resistance. I’ll see if I can dig something up and suggest some wording. 
>> 
>> Your wording does look pretty good though so maybe we don’t need to be too formal about this?
> 
> Agree, I'm certainly okay going with that wording and not being too formal. Will plan on making those updates. 
> 
>  
> <snip><snip> 
> 
> 
>> 
>> What I want to ensure is that a migration path like the following works:
>> 
>> 1. at some future point in time the WG becomes aware of attack A and develops backwards-compatible mitigation M (think PKCE for example)
>> 
>> 2. verifiers roll out support for M
>> 
>> 3. issuers/holders gradually roll out support for M
>> 
>> Between steps 2 and 3 there can be verifiers that support the enhanced security but are dealing with a mixture of clients that do or do not support the new mitigation. This is where hard-coded requirements in the verifiers can cause issues, because it means you can’t turn on the new mitigation until all clients support it. Or the verifiers have to have complex rules about which clients support some mitigation and which don’t (a la user-agent sniffing). 
>> 
>> It’s much better to say “if there’s a code_challenge (or cnf or …) on this request then enforce it”. 
> 
> A verifier having an acceptance policy doesn't preclude conditional treatment of a new claim like that. We are certainly not trying to preclude or hinder future evolvability. I don't read the current text as disallowing a migration path like you've described. But maybe there's room for adjustment/improvement in the text so as to avoid giving that impression? 

The current wording of section 11.6 says:

“Verifiers MUST NOT take into account […] whether Key Binding data is present in the SD-JWT or not[…]”

While 11.8 says:

"Verifiers therefore MUST ensure that all claims they deem necessary for checking the validity of the SD-JWT are present (or disclosed, respectively) before checking the validity and accepting the SD-JWT"

I think these constraints do rule out the migration path that I described. I don’t see how a service could incrementally and securely roll-out support for Key Binding (for example) over time—starting from a base ecosystem that isn’t using Key Binding. Either they would have to suddenly *require* Key Binding, and therefore start rejecting clients that haven’t updated yet, or they may have the situation where a stolen key-bound SD-JWT can be treated as a simple bearer token by not selectively-disclosing the cnf claim.

Concretely, I think these phrases and section 8.4 should be removed/re-written.

> 
>  <snip><snip>
>>> 
>>> The 11.8 section could perhaps be stronger in saying that claims controlling the validity of the token shouldn’t be made selectively disclosable. But what exactly constitutes such a claim is actually rather murky and there are undoubtedly exceptions like you point out with “aud”.
>> 
>> It may be murky but I think we do need to try and look at this. I’m happy to think about some text to suggest here. 
> 
> Such suggested text would be very welcome and helpful. I just don't think it's feasible or realistic to have one exhaustive or complete listing of claims that can't/shouldn't be made selectively disclosable. But would be very open to tightening up and strengthening and improving this section.  

How about the following:

—
An Issuer MUST NOT allow any security-critical claim to be selectively disclosable. The exact list of “security-critical” claims will depend on the application, and SHOULD be listed by any application-specific profile of SD-JWT. The following is a list of standard claim names that SHOULD be considered as security-critical by any SD-JWT Issuer:

 * “iss” (Issuer)
 * “aud” (Audience), although issuers may want to allow individual entries in the array to be selectively-disclosable
 * “exp” (Expiration Time)
 * “nbf” (Not Before)
 * “iat” (Issued At)
 * “jti” (JWT ID)

In addition, the “cnf” (Confirmation Key) claim MUST NOT be selectively disclosable.
---
<snip>

Best wishes,

Neil