Definitely; thanks for raising that explicitly. -Ben
On Fri, Jan 17, 2020 at 04:34:10PM +0000, Richard Backman, Annabelle wrote: > We should not be prescriptive about how the AS recognizes request URIs from > itself. Trusted authority or custom URI scheme are fine as examples, but > ultimately this is an internal implementation of the AS. It could just as > easily be using data URIs containing a symmetrically encrypted database > record ID. > > > On Jan 16, 2020, at 8:00 PM, Benjamin Kaduk <ka...@mit.edu> wrote: > > > > On Thu, Jan 16, 2020 at 04:31:30PM +0000, Neil Madden wrote: > >> The mitigations of 10.4.1 are related, but the section heading is about > >> (D)DoS attacks. I think this heading needs to be reworded to apply to SSRF > >> attacks too or else add another section with similar mitigations. > >> > >> Mitigation (a) is a bit vague as to what an "unexpected location" is. > >> Perhaps specific wording that it should be a URI that has been > >> pre-registered for the client (and validated at that time) or is otherwise > >> known to be safe (e.g., is a URI scheme controlled by the AS itself as > >> with PAR). > > > > pedantic nit: "URI scheme" is probably not what we want, as the authority > > component of the URI (per RFC 3986) seems more likely to match "controlled > > by the AS itself" > > > > -Ben > > > >> In addition for this to be effective the AS should not follow redirects > >> when fetching the URI. It's not clear to me whether that is implied by > >> "not perform recursive GET" so it may be worth explicitly spelling that > >> out. > >> > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
