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
