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 protected]> wrote: > 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: >>> >>> 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 > > _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
