Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

Vladimir Dzhuvinov <> Wed, 09 December 2020 08:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F9303A0E57 for <>; Wed, 9 Dec 2020 00:45:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ASKdES3Z02zk for <>; Wed, 9 Dec 2020 00:45:48 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A8BC3A0365 for <>; Wed, 9 Dec 2020 00:45:48 -0800 (PST)
Received: from [] ([]) by :SMTPAUTH: with ESMTPSA id mv6Yks6PRJwSFmv6YkobKl; Wed, 09 Dec 2020 01:45:47 -0700
X-CMAE-Analysis: v=2.4 cv=dcRFYVbe c=1 sm=1 tr=0 ts=5fd08ebb a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=8HkmfUwDAAAA:20 a=48vgC7mUAAAA:8 a=yCE9nInwAAAA:8 a=A1X0JdhQAAAA:8 a=AoMLT2mTcbODp-Ium70A:9 a=QEXdDO2ut3YA:10 a=pGLkceISAAAA:8 a=jRJ-pIbmMatcFnQ4BfsA:9 a=JWUEXBTJH14ar9yh:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=n6bEelttlQx3_n4Es6hb:22 a=Df3jFdWbhGDLdZNm0fyq:22 a=EGhOoitCJuQMvEZ8ckLK:22 a=pHzHmUro8NiASowvMSCR:22 a=n87TN5wuljxrRezIQYnT:22
References: <> <> <> <> <> <> <> <> <>
From: Vladimir Dzhuvinov <>
Autocrypt:; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: <>
Date: Wed, 09 Dec 2020 10:45:45 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms000802010905090708080801"
X-CMAE-Envelope: MS4xfGp7M2g+bqlSOCyYW5yHmh0/YGqeHRKzMoUBkbYCLQGJuaXZCXJj4zklc2cZWBnL1Epg7xPpMzN3Dpd/HA6Q7TjIEzehc4vgxQu/6wtEScGyj6oVi4YW rL5E3F8F4GbAmQIKCGv/5bFH8/oH23woHBULkO3W6Gt3KgRp68hmunHaV2yqNgiw5heL+s1PjpAMcg==
Archived-At: <>
Subject: Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Dec 2020 08:45:50 -0000

Do we have deployments in the field and client-side developers giving
feedback / comments about the current DPoP, implementing it, and perhaps
those concerns about the access token?


On 08/12/2020 23:47, Brian Campbell wrote:
> Danial recently added some text to the working copy of the draft with
> that I think
> aims to better convey the "nutshell: XSS = Game over" sentiment and
> maybe dissuade folks from looking to DPoP as a cure-all for browser
> based applications. Admittedly a lot of the initial impetus behind
> producing the draft in the first place was born out of discussions
> around browser based apps. But it's neither specific to browser based
> apps nor a panacea for them. I hope the language in the document and
> how it's recently been presented is reflective of that reality.
> The more specific discussions/recommendations around in-browser apps
> are valuable (if somewhat over my head) but might be more appropriate
> in the OAuth 2.0 for Browser-Based Apps
> <>
> draft.
> With respect to the contents of the DPoP draft, I am still keen to try
> and flush out some consensus around the question posed in the start of
> this thread, which is effectively whether or not to include a hash of
> the access token in the proof.  Acknowledging that "XSS = Game over"
> does sort of evoke a tendency to not even bother with such incremental
> protections (what I've tried to humorously coin as "XSS Nihilism" with
> no success). And as such, I do think that leaving it how it is (no AT
> hash in the proof) is not unreasonable. But, as Filip previously
> articulated, including the AT hash in the proof would prevent
> potentially prolonged access to protected resources even when the
> victim is offline. And that seems maybe worthwhile to have in the
> protocol, given that it's not a huge change to the spec. But it's a
> trade-off either way and I'm personally on the fence about it.
> Including an RT hash in the proof seems more niche. Best I can tell,
> it would guard against prolonged offline access to protected resources
> when access tokens are bearer and the RT was DPoP-bound and also gets
> rotated. The trade-off there seems less worth it (I think an RT hash
> would be more awkward in the protocol too).
> On Fri, Dec 4, 2020 at 5:40 AM Philippe De Ryck
> <
> <>> wrote:
>>     The suggestion to use a web worker to ensure that proofs cannot
>>     be pre-computed is a good one I think. (You could also use a
>>     sandboxed iframe for a separate sub/sibling-domain -
>> <>).
>     An iframe with a different origin would also work (not really
>     sandboxing, as that implies the use of the sandbox attribute to
>     enforce behavioral restrictions). The downside of an iframe is the
>     need to host additional HTML, vs a script file for the worker, but
>     the effect is indeed the same.
>>     For scenario 4, I think this only works if the attacker can
>>     trick/spoof the AS into using their redirect_uri? Otherwise the
>>     AC will go to the legitimate app which will reject it due to
>>     mismatched state/PKCE. Or are you thinking of XSS on the
>>     redirect_uri itself? I think probably a good practice is that the
>>     target of a redirect_uri should be a very minimal and locked down
>>     page to avoid this kind of possibility. (Again, using a separate
>>     sub-domain to handle tokens and DPoP seems like a good idea).
>     My original thought was to use a silent flow with Web Messaging.
>     The scenario would go as follows:
>     1. Setup a Web Messaging listener to receive the incoming code
>     2. Create a hidden iframe with the DOM APIs
>     3. Create an authorization request such as
>     “//authorize?response_type=code&client_id=...&
>     <>&state=...&code_challenge=7-ffnU1EzHtMfxOAdlkp_WixnAM_z9tMh3JxgjazXAk&code_challenge_method=S256&prompt=none&response_mode=web_message/”
>     4. Load this URL in the iframe, and wait for the result
>     5. Retrieve code in the listener, and use PKCE (+ DPoP if needed)
>     to exchange it for tokens
>     This puts the attacker in full control over every aspect of the
>     flow, so no need to manipulate any of the parameters.
>     After your comment, I also believe an attacker can run the same
>     scenario without the “/response_mode=web_message/”. This would go
>     as follows:
>     1. Create a hidden iframe with the DOM APIs
>     2. Setup polling to read the URL (this will be possible for
>     same-origin pages, not for cross-origin pages)
>     3. Create an authorization request such as
>     “//authorize?response_type=code&client_id=...&
>     <>&state=...&code_challenge=7-ffnU1EzHtMfxOAdlkp_WixnAM_z9tMh3JxgjazXAk&code_challenge_method=S256/”
>     4. Load this URL in the iframe, and keep polling
>     5. Detect the redirect back to the application with the code in
>     the URL, retrieve code, and use PKCE (+ DPoP if needed) to
>     exchange it for tokens
>     In step 5, the application is likely to also try to exchange the
>     code. This will fail due to a mismatching PKCE verifier. While
>     noisy, I don’t think it affects the scenario. 
>>     IMO, the online attack scenario (i.e., proxying malicious
>>     requests through the victim’s browser) is quite appealing to an
>>     attacker, despite the apparent inconvenience:
>>      - the victim’s browser may be inside a corporate firewall or
>>     VPN, allowing the attacker to effectively bypass these restrictions
>>      - the attacker’s traffic is mixed in with the user’s own
>>     requests, making them harder to distinguish or to block
>>     Overall, DPoP can only protect against XSS to the same level as
>>     HttpOnly cookies. This is not nothing, but it means it only
>>     prevents relatively naive attacks. Given the association of
>>     public key signatures with strong authentication, people may have
>>     overinflated expectations if DPoP is pitched as an XSS defence.
>     Yes, in the cookie world this is known as “Session Riding”. Having
>     the worker for token isolation would make it possible to enforce a
>     coarse-grained policy on outgoing requests to prevent total abuse
>     of the AT.
>     My main concern here is the effort of doing DPoP in a browser
>     versus the limited gains. It may also give a false sense of security. 
>     With all this said, I believe that the AS can lock down its
>     configuration to reduce these attack vectors. A few initial ideas:
>     1. Disable silent flows for SPAs using RT rotation
>     2. Use the sec-fetch headers to detect and reject non-silent
>     iframe-based flows
>     For example,  an OAuth 2.0 flow in an iframe in Brave/Chrome
>     carries these headers:
>     /
>     sec-fetch-dest: iframe
>     sec-fetch-mode: navigate
>     sec-fetch-site: cross-site
>     sec-fetch-user: ?1
>     /
>     Philippe
> /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./
> _______________________________________________
> OAuth mailing list

Vladimir Dzhuvinov