Thanks for the update! I've replied below with [IM2], but also top-posted a part of your previous email that I skipped by mistake, to which I've now replied.
From: Brian Campbell <[email protected]<mailto:[email protected]>> Date: Friday, 16 October 2026 at 13:42 To: Ionut Mihalcea <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]><[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: Re: draft-ietf-oauth-sd-jwt-vc-19 ietf last call Secdir review <snip> * In Section 7.1 you mandate that "the Consumer MUST validate the URL to ensure that it is a valid HTTPS URL and that it does not point to internal resources". Two observations here: this could be subject to a DNS rebinding attack, so it would be good to hint towards that and ask that the destination address get cached and used after check, instead of performing another request for it. Is there some straightforward and reasonably actionable text you could suggest? I am not well versed in DNS rebinding attacks, their impact, or their mitigations. But, given the layering involved and the APIs these applications likely use, ensuring that kind of caching is probably not at all trivial. [IM2] Regarding layer-crossing, section 7.1 seems to already cross the stack for DNS considerations. I can recommend a minor text change. Paragraph 2 in 7.1 currently says: "Before making a request ... ensure ... the resolved DNS name does not point to an internal IP address." (the omissions skip through the paragraph, but that's the spirit of the text). I'd recommend: "When making a request ... the Consumer MUST ensure that the URL does not resolve or connect to an internal IP address. Performing DNS validation separately from the HTTP connection may allow DNS rebinding ([OWASP_SSRF])." Having the DNS check before enables the TOCTOU that DNS rebinding needs. [IM2] Nit: the OWASP_SSRF link has a spurious '/' at the end. <snip> From: Brian Campbell <[email protected]> Date: Thursday, 22 October 2026 at 23:54 To: Ionut Mihalcea <[email protected]> Cc: secdir <[email protected]>; [email protected] <[email protected]>; Last Call <[email protected]>; oauth <[email protected]>; nd <[email protected]> Subject: Re: draft-ietf-oauth-sd-jwt-vc-19 ietf last call Secdir review <snip> [IM] The starting point is a domain under which privileged control is maintained over the well-known endpoint ( example.com/.well-known<http://example.com/.well-known> ) but other entities might upload random content to other paths ( example.com/upload/.<http://example.com/upload/.>.. ). If the attacker provides the issuer URL as 'example.com/../../upload/mal.json<http://example.com/../../upload/mal.json>' the well-known GET request will land on example.com/upload/mal.json<http://example.com/upload/mal.json> , which would serve metadata under the attacker's control. For some consumers this might make them assume the attacker is authorised by example.com<http://example.com> . Does this make sense, and does it raise any concern? Thank you for the explanation, which does make sense. I'm a little uncertain, to be honest, but I'm inclined to say that because issuer values are treated as literal string values (even when they are URLs) and the draft requires "employing a key discovery and validation mechanism (defined in Section 2.5) that is permitted for the Issuer according to policy", that an issuer value of "https://example.com/../../upload/mal.json"; is exactly that value, distinctly different from "https://example.com/";. Does that make sense? Am I overlooking something, do you think? [IM2] Sure, you understand the policies at this level of the stack, and how they're applied, better. Just wanted to raise this in case it's a worry on your side. <snip> [IM] Indeed, I'll have another look in case I find some workable suggestion. We did come up with some text regarding this, and updated the PR with it after the email. Please take a look at that before spending any cycles working on a suggestion. That text is around here https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/443/changes#diff-e750c0958ca10e395b4d3b77bb5aafccc668b4a1a50675dda79a8d90b39a2468R1094 [IM2] Ok, checking now! Apologies for the delay <snip> [IM] I think the MUST is needed, maybe changing the last part of the sentence to something like "... and that it does not point to resources an issuer cannot access (e.g., resources internal to the Consumer)"? That makes sense, thanks, I've updated the PR accordingly with this change https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/443/changes/f18983572aa191b5b2e3da60fc25e9ce8df5f856 [IM2] ACK
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
