I love you Neil. -- Jim Manico @Manicode
> On Oct 30, 2019, at 3:18 PM, Neil Madden <neil.mad...@forgerock.com> wrote: > > > If you can point out where I recommended disabling TLS or not bothering to > strip headers from incoming requests, or anything else along those lines then > please let me know. Otherwise, yes we’re done here. > >>> On 30 Oct 2019, at 17:19, Salz, Rich <rs...@akamai.com> wrote: >>> >> >> To quote your previous claim: "There is no such thing as an unguessable >> name." >> Right. That doesn’t mean *I* have to guess it. >> >> Even if your deployment team had such staggeringly bad operational security >> practices as to allow people to take packet captures from an internal >> network and show them on public slides without any kind of questions being >> asked, if this actually happens *YOU ARE NO WORSE OFF THAN IN THE SITUATION >> WHERE YOU USED A WELL-KNOWN HEADER NAME*! >> Yes you are worse off. Because that now-exposed header value can be used >> for spoofing. As opposed to protection by TLS, and then sending the >> plaintext message around. >> >> I don't know how many different ways I can say that this is a defense in >> depth >> Because it is not. It is taking an application-level piece of configuration >> data and requiring it to be treated as if it were crypto material. Which it >> cannot be, because multiple parties need to know it (as I said, the proxy, >> the backend, the app developers, the support team, etc). It’s defense by >> “collapsing layers” rather than “in depth.” >> >> As with all defense in depth, the aim is to be more than 1 configuration >> mistake away from total compromise. >> But that is exactly what you are proposing. Exposing the header *is* a total >> compromise and multiple entities will need to know that header value. >> >> At any rate, I think we’re done here. >> > _______________________________________________ > 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
