Re: [websec] Authentic inter-domain relationships. Is this a security problem? Appropriate for websec?

[Jeffrey Walton <[e-mail]>]

> 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 <[e-mail]> 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,
>