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

[Tobias Gondrom <[e-mail]>]

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




On 20/01/15 01:22, Chris Hartmann wrote:
> 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
> <[e-mail]> 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 <[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,
>>>>
>>> _______________________________________________
>>> websec mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/websec
>>