Subject: Re: [OAUTH-WG] New Version Notification for draft-ietf-oauth-dpop-01.txt

From: Brian Campbell <[email-masked]>
Date: Fri, 6 Nov 2020 15:02:07 -0700

On Tue, May 5, 2020 at 2:52 PM Brian Campbell <[email-masked]>
wrote:

>
>
>> 9.1:
>> This would be a good place to mention BREACH as an example of how a DPoP
>> proof (and AT) might leak, despite only being sent over a direct HTTPS
>> channel. Note though that adding a random jti is an effective defence
>> against this even if the server doesn’t check it.
>>
>
> Thanks for that note as a good reason to keep jti even if the requirements
> on checking it are relaxed.
>

In trying to add some text that makes such mention I realized (again) that
I don't have a very good understanding of BREACH. With a bit of reading of
the overview and paper at http://breachattack.com/ it seems that BREACH is
applicable to attacking compression for leaking sensitive information in
HTTP responses. Whereas a DPoP proof is only defined to be sent in an HTTP
request. And ATs are only in a response once and then used in requests.
Perhaps it's a limitation of my own imagination or intellect but I don't
see how BREACH is relevant here. If you can explain it to me "for dummies"
style or better yet propose some text, we can certainly look at adding it.
Short of that though, I'm not equipped to write anything legitimate about
it and will just omit any such mention.

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

---

From: Neil Madden <[email-masked]>
Date: Sat, 7 Nov 2020 15:30:14 +0000

> On 6 Nov 2020, at 22:02, Brian Campbell <[email-masked]> wrote:
> 
> 
> 
> 
>> On Tue, May 5, 2020 at 2:52 PM Brian Campbell <[email-masked]> wrote:
>> 
>>> 
>>> 9.1:
>>> This would be a good place to mention BREACH as an example of how a DPoP proof (and AT) might leak, despite only being sent over a direct HTTPS channel. Note though that adding a random jti is an effective defence against this even if the server doesn’t check it.
>> 
>> Thanks for that note as a good reason to keep jti even if the requirements on checking it are relaxed. 
> 
> In trying to add some text that makes such mention I realized (again) that I don't have a very good understanding of BREACH. With a bit of reading of the overview and paper at http://breachattack.com/ it seems that BREACH is applicable to attacking compression for leaking sensitive information in HTTP responses. Whereas a DPoP proof is only defined to be sent in an HTTP request. And ATs are only in a response once and then used in requests. Perhaps it's a limitation of my own imagination or intellect but I don't see how BREACH is relevant here. If you can explain it to me "for dummies" style or better yet propose some text, we can certainly look at adding it. Short of that though, I'm not equipped to write anything legitimate about it and will just omit any such mention.  
>  

BREACH was primarily attacking web browser clients, which do indeed usually only allow compression in responses. But OAuth is used for other API clients and compression of requests, although by no means widespread, is sometimes used. For example [1] where it’s recommended that clients use compression for both requests and responses, and a Google search shows various other cases. 

So in these cases a BREACH-like attack could be used to recover a bearer token in those requests. However, on reflection it’s not a hugely likely attack vector for a number of reasons:

1. HTTP compression only compresses the request entity, not the headers or request URI. So this would only be a risk when sending the access token in the body as in [2]. And it’s not a risk for a DPoP proof as that’s always in a header. 

2. In order for the attack to work the attacker needs to be able to influence some part of the requests, which is generally a bit harder than influencing responses from a server. The most likely vector IMO would be XSS, in which case there are likely to be more direct ways to steal the token. 

I wouldn’t want to say that this is never a risk, but it perhaps doesn’t rise to the level that it’s worth spelling out. 

[1]: https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/intro_rest_compression.htm

[2]: https://tools.ietf.org/html/rfc6750#section-2.2

— Neil
-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>