> Is this a security problem? I think so. Yes. Knowing the relationship would be helpful in a security context.
> I have a few ideas on how this could be improved/implemented. Dbound is poking and prodding at related issues. And they are finalizing their charter now. You might consider reading some of the recent posts and commenting. https://www.ietf.org/mailman/listinfo/dbound. Jeff On Mon, Jan 12, 2015 at 2:18 PM, Chris Hartmann <[email protected]> wrote: > 1) Bob trusts and does personal business with a.com. > > 2) a.com forms a business relationship with b.com to perform a > business function on its behalf (payment processor, blog, whatever). > The landing page is b.com/a > > 3) Bob visits b.com/a and notices that the page claims to be > affiliated and owned by a.com > > 4) How can Bob, in absolute terms, trust that b.com/a is affiliated > and a delegated service by a.com? (say, prior to submitting sensitive > information) > > Is this a security problem? I think so. > > We’ve all had to make this decision one time or another on weak > inferences and correlations. I’d imagine Phishers don’t mind at all > that there is an inability for the common internet user (looking at > you grandma) to make the judgement call on web service affiliations. > They’ve been conditioned with the best practice of looking at the > address bar (and perhaps the DNS namespace) along with the lock icon > to indicate trustworthiness, which may actually help the attacker in > their act of misdirection. Inter-domain relationships model business > relationships and trust. If web users could be armed with a new > “sense” which proves these legitimate relationships (say > cryptographically) then perhaps they would have more reason to be > skeptical of those who cannot prove their affiliation. I’m not saying > we can take human judgement completely out of the equation, but why > not have a tool to help anchor this commonly needed and risky > correlation. > > Eg: > > 5) https://c.com/a is a bad guy and claims the same thing as b.com/a . > Now who to trust becomes a research project. (But c.com has the https > lock icon, doesn’t that count for anything: NO) > > > Use case a) Tim submits a payment to a redcross.org Paypal donation > page he found via his favorite search engine. It was a scam. (We can > argue a violation of "best practices" here, but that is besides the > point) > > > I suppose phishing isn’t the only example. It could apply to any case > where you want to logically group the identity of one entity across > many domain boundaries owned by different parties. (eg. A popular band > has many web points of presence for fans, etc). This same mechanism > could “certify” that these web assets are under one umbrella, although > they don’t exist under one domain hierarchy. > > Should we solve this? Is it solved already? Could use help gelling or > junking this idea. > > I have a few ideas on how this could be improved/implemented. > > Cheers, > _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
