On Tue, May 5, 2020 at 2:52 PM Brian Campbell <bcampb...@pingidentity.com> 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._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
