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

[Brian Campbell <[e-mail]>]

Hi Neil. Thank you for suggesting text! I agree we’re closing in on some
actionable changes here (I've added some issues in the github repo to keep
track FWIW) and we'll work to incorporate the text you've suggested.

I do see how the text you've cited in 11.8 11.6, and 8.3 (there is no 8.4
so making an assumption) could be read as ruling out the kind of migration
path you've described (though admittedly I have a more liberal reading). I
do agree that we don't want to outright disallow that kind of migration.
But I want to be really thoughtful about any changes that might be made in
that area. I think it's very important to convey the general
principle/requirement that a verifier have a validation policy that isn't
unduly/unexpectedly influenced by the (sometimes attacker-controllable)
content of the token. A verifier's policy might have some conditionality as
appropriate for a specific context (such as migration) but the verifier has
to have a concrete policy around validation and acceptance.


On Mon, Nov 6, 2023 at 6:44 AM Neil Madden <[e-mail]> wrote:

> 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]>
> wrote:
>
> On 25 Oct 2023, at 22:00, Brian Campbell <[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
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._