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

[Brian Campbell <[e-mail]>]

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?

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?


 <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.



>
> And I know some have expressed the need/desire to have key/holder binding
> type claims (such as “cnf” but not only that) be made selectively
> disclosable for privacy reasons.
>
>
> Making cnf selectively disclosable seems like a security disaster to me.
> It means that if an attacker steals such a token they can basically treat
> it as a bearer token and not disclose that it is key-bound. (Unless the
> verifiers enforce only key-bound tokens, which can be difficult as I’ve
> said). My prediction is that if we allow this it will cause security
> issues.
>

I agree that it could be problematic. I was only mentioning the fact that
I'd heard some express the need/desire. And, as I recall, it wasn't
actually about cnf specifically. So being stronger about not making cnf
selectively disclosable would be okay I think.




> I also don’t think a new registry would really help the situation.  At
> this level we're describing a generic mechanism and don’t necessarily even
> have a list of all claims that could be interpreted as constraints in a
> particular context or application. Note, for example though, that
> https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/ does say
> that certain claims must be included directly and not made selectively
> disclosable.
>
> Which leads back to ultimately needing that requirement that Verifiers
> ensure that all the claims they deem necessary are present (in the clear or
> disclosed) when checking the validity and accepting the token.
>
>
> Which I think harms future evolvability. I don’t think it would be too
> hard to add a new column to the IANA JWT standard claims list to indicate
> selective disclosability - “allowed”, “never”, “per-item” or something like
> that.
>

I think you might underestimate the difficulty in
creating/changing/establishing such a registry and overestimate its
effectiveness and usefulness. And I think the  selective disclosability
treatment of many claims is ultimately context dependent. As I've said, I'm
all for strengthening and improving the text in this section. But don't
believe that involves a registry.




>
>
>> 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.
>>
>>
> It’s not meant to preclude that kind of thing (and reading it again, I
> don’t think it does preclude it). But rather to just say that whatever the
> Verifier’s requirements on key binding are have to be based on its policy
> and not on the content of the token (some of which could be manipulated by
> the holder). A Verifier’s policy could, as you describe, afford different
> levels of access based on different security characteristics of the
> presented token/credential. Or the Verifier’s requirements could, for
> example, say that for credential type A, Key Binding is always required,
> while for credentials of type B, it is only required when the credential
> was issued by an issuer that is known to issue credentials supporting Key
> Binding.
>
>
> This assumes that the issuer is not selectively discloseable…
>

Issuer probably shouldn't be made selectively discloseable in many/most
cases but I think even that is ultimately context dependent.  And anyway, a
token would fail that acceptance policy, if iss was omitted or not
disclosed. Which seems appropriate and still confirming of the whole idea
of a verifier needing to have a policy around acceptance (even one that has
conditionality).

-- 
_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._