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

From: Chris Hartmann <[email-masked]>
Date: Mon, 12 Jan 2015 11:18:58 -0800

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,

Chris

P.S. First post here, been lurking for a while now.

---

From: Anne van Kesteren <[email-masked]>
Date: Tue, 13 Jan 2015 10:09:18 +0100

> I have a few ideas on how this could be improved/implemented.

I'd be interested to hear them. E.g. at work we started using
https://www.okta.com/ to login to a bunch of a services, including
e.g. Google services. It felt extremely phishy to give credentials to
okta.com to make use of a google.com service.

-- 
https://annevankesteren.nl/

---

From: Gervase Markham <[email-masked]>
Date: Tue, 13 Jan 2015 10:40:44 +0000

> The landing page is b.com/a

Would it not be reasonable to say that, when this sort of relationship
is set up, best practice is to do DNS delegation so that the landing
page is on b.a.com or some other subdomain of a.com?

> affiliated and owned by a.com

...because then, both the DNS info and the claim would match.

> and a delegated service by a.com? (say, prior to submitting sensitive

Because the domain used is a subdomain of a.com.

Gerv

---

From: Chris Hartmann <[email-masked]>
Date: Tue, 13 Jan 2015 12:30:58 -0800

Hi Anne/All,
Thanks for the response.

I think your use-case is slightly different then what I was going for,
but perhaps I can extend my idea to cover a different aspect of yours.
Just for clarity, if I understand correctly, the relationship between
services like okta.com and google.com isn't what I'm addressing
(sounds more OAuth'ish etc). Rather the relationship between you, your
employer, and okta.com might be more in line with where I'm going, but
still isn't really the primary case. Let me explain, in your case, you
or your company IT department made a judgement call to trust okta.com
with managing a business asset, business related accounts used for
business purposes hosted by a third-party. Presumably your credentials
to okta.com are a risk to the company if compromised. If a phisher
sent you an email claiming to be okta.com with a link to a fake but
believable hostname, say otka.com (see what I did there), you happen
to click the link and are on the verge of providing your credentials,
you are now in a situation where your perception of the hostname is
the only indication to spark your skepticism and avoid compromise.
Exactly the edge phishers hope for.

My vague idea is that the user agent should have the capability to
notify you, the end-user, that there is no relationship between
yourcompany.com and otka.com (the bad guy), perhaps in a similar
manner that browsers today indicate a lack of integrity with regards
to https verification failures.

Instead of the user-agent labeling the bad guy as bad, it would be the
opposite. When yourcompany.com formed the business relationship with
okta.com it could perhaps share a bit of digitally signed data, say
digitally sign the url to the login page (www.okta.com/yourcompany)
and embed that in response. Then the user-agent would be able to
notify you each time you log in that yourcompany.com authorized
www.okta.com/yourcompany in an obvious enough manner for you to notice
it missing when you clicked the phishing link. In a sense my hope is
to label the good relationships as truthfully good, the user-agent
constantly labels it as such, and then the hope is that typical end
users can then be skeptical when the "this is the good guy" label is
missing, enhancing human perception of good vs. evil.

All of this is very specific, but in general, at the core, I think as
orgs continue the trend of "outsourcing IT" there needs to be a way on
the web to describe and authenticate the relationships in a manner
that end-users and user-agents can digest.

Making a lot of assumptions and going out on a limb here, but a fun
little thought experiment, and look forward to continuing the
brainstorm.

Chris

---

From: Chris Hartmann <[email-masked]>
Date: Tue, 13 Jan 2015 13:32:06 -0800

> page is on b.a.com or some other subdomain of a.com?

Absolutely. However my impression is that isn't the common practice
for two parties to integrate at this level consistently.

For example a google search can show the organizations that presumably
have web presence that is theirs, but how do I _know_ in an undeniable
manner that they are a subsidy of their parent domain.

https://www.google.com/webhp?#q=imagine+dragons+-site:imaginedragonsmusic.com

https://www.google.com/search?q=cnn%20-site%3Acnn.com

Yeah we all make conscious cross references here, which can give us a
pretty good sense of correlation, and usually guessing wrong isn't
catastrophic. Sometimes the third-parties do make efforts to assure
users that the landing pages are "verified" as authentic, but that is
pretty weak. My argument is that this doesn't have to be hearsay or a
manual correlation effort, the user-agent be able to tell us the
truth.

This might seem trivial and unnecessary which is a valid argument in
some cases, but my belief is that this is one of the core properties
that makes phishing attempts more murky to end users for the corner
cases that matter. This is what I would hope to fix.

---

From: Jeffrey Walton <[email-masked]>
Date: Tue, 13 Jan 2015 19:44:37 -0500

> 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

---

From: Anne van Kesteren <[email-masked]>
Date: Wed, 14 Jan 2015 10:15:30 +0100

On Tue, Jan 13, 2015 at 9:30 PM, Chris Hartmann <[email-masked]> wrote:
> If a phisher

Yeah, that's the concern.

> When yourcompany.com formed the business relationship with
> and embed that in response.

Given that the current address bar UI already has limited utility,
it's not clear to me what making it more complicated will actually
help users.

---

From: Tobias Gondrom <[email-masked]>
Date: Wed, 14 Jan 2015 12:16:52 +0000

Hi Chris, hi all,

let me say, I can see a missing link here which would be nice to solve.

Btw. another example coming to mind would be the connection with 
external payment services or increasing number of references to cloud 
based services (where it is not sure that a.com is indeed using b.com).
E.g. e-commerce sites linking to paypal or Mastercard / Visa vericode 
(or whatever they call it) directly out of the e-commerce site...

Some improvement in the trust chain could indeed be valuable here.

Having said that, if another WG is already working in this area - Jeff 
mentioned dbound - then my recommendation would be to take the work 
there. WEBSEC is about to be closed, we are only waiting for the final 
release of our last document.

Best regards, Tobias

On 14/01/15 00:44, Jeffrey Walton wrote:
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: Chris Hartmann <[email-masked]>
Date: Wed, 14 Jan 2015 13:34:55 -0800

> it's not clear to me what making it more complicated will actually

Yeah, I also have the sense any proposed UA/UI change is going to be
highly scrutinized and be a point of resistance. But I have yet to
conclude how social engineering attacks can be comprehensively
addressed without at least partially arming end users with something
to help them make these important correlations. Trust by affiliation
is a real thing that we do in the real world, although these
affiliations are hard to verify, they work in general. In the digital
world fortunately we can have machines verify these affiliations with
an extremely high level of certainty, I'd argue people should be able
to perceive these to formulate trust.

---

From: Igor Bukanov <[email-masked]>
Date: Thu, 15 Jan 2015 15:26:54 +0100

On 13 January 2015 at 21:30, Chris Hartmann <[email-masked]> wrote:
> Presumably your credentials

SRP [1] and J-Pake [2] protocols solved that problem long time ago -
the idea is that one use a password not only to authenticate self to a
host but also to verify that the host does know your password without
reveling the password to the host. Unfortunately the browser support
is lacking, so one needs a browser extension to support that.

[1] - http://srp.stanford.edu/
[2] - http://en.wikipedia.org/wiki/Password_Authenticated_Key_Exchange_by_Juggling

---

From: Chris Hartmann <[email-masked]>
Date: Mon, 19 Jan 2015 17:22:50 -0800

Thanks Jeff, Tobias.

Yes, dbound does seem to resonate pretty well with where I was going
here. Ironic and fortunate to catch it now while it's still
crystalizing. Although I believe there is room to contemplate
extending the concept beyond pure DNS namespace relationships (I'd
like to see URI<->URI), some of the core problems/principals seem to
be the same, great.

Chris

On Wed, Jan 14, 2015 at 4:16 AM, Tobias Gondrom
<[email-masked]> wrote:
> Btw. another example coming to mind would be the connection with external
> payment services or increasing number of references to cloud based services
> (where it is not sure that a.com is indeed using b.com).
> E.g. e-commerce sites linking to paypal or Mastercard / Visa vericode (or
> whatever they call it) directly out of the e-commerce site...
>
> mentioned dbound - then my recommendation would be to take the work there.
> WEBSEC is about to be closed, we are only waiting for the final release of
> our last document.
>
> Best regards, Tobias
>
>
>
>
>

---

From: Tobias Gondrom <[email-masked]>
Date: Tue, 20 Jan 2015 01:30:35 +0000

Hi Chris,

good to hear.

And just to add: even without websec, if you think something that goes 
beyond DNS namespace relationships or the scope of the other WG is 
needed, at the IETF there is also the possibility for individual 
submissions. Downside with individual drafts is, it is much harder to 
get good community review and assemble a team working on the draft. But 
this option is available.

All the best, Tobias