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

Jeffrey Walton <noloader@gmail.com> Wed, 14 January 2015 00:44 UTC

Return-Path: <noloader@gmail.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D361ACE23 for <websec@ietfa.amsl.com>; Tue, 13 Jan 2015 16:44:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LM6O0-nxLyUs for <websec@ietfa.amsl.com>; Tue, 13 Jan 2015 16:44:39 -0800 (PST)
Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4F711ACE20 for <websec@ietf.org>; Tue, 13 Jan 2015 16:44:38 -0800 (PST)
Received: by mail-ig0-f174.google.com with SMTP id hn15so19993126igb.1 for <websec@ietf.org>; Tue, 13 Jan 2015 16:44:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=dEMN7/nbQ8+Jx/umaQrDDN8GzruXsb92Xcnl6u/rYsI=; b=UAuRsyp2jN3N9uQAeWR8FjYNhQW9Rm0stUhnpnqQnHCZe+m0WWKpcxpWTZtKPtBB+E QssXZBJGKbnp3+4h8BmRuxi70QDLvqjD6t8EYIO+zAdURKjHozFc2oM6a8z8+cwIP009 kC8iAMfE2alouyjAolDVDomgxCcN5DZ4+UWWYU/FSVUwOuESUlVbgEzB4OL0lfM7GMVb CZ9zI9Vg8r0i6dF1H5C3+NSiR1rGEXaASl45TT72ykDU/d2dXJUrd+86Kfv7aiX+PAml IUFcYCB8B1TjH2unEltrY1RSaiEQziskqyWFc5V98wb6HCsBuetaa1VEXxIsGYkrEObT vXSA==
MIME-Version: 1.0
X-Received: by 10.50.66.171 with SMTP id g11mr1454949igt.49.1421196277943; Tue, 13 Jan 2015 16:44:37 -0800 (PST)
Received: by 10.107.134.170 with HTTP; Tue, 13 Jan 2015 16:44:37 -0800 (PST)
In-Reply-To: <CAL1pEULxwcStS6EDfYtpV+neU2izz2gLsJi2Ak7OVxB9x8MzhA@mail.gmail.com>
References: <CAL1pEULxwcStS6EDfYtpV+neU2izz2gLsJi2Ak7OVxB9x8MzhA@mail.gmail.com>
Date: Tue, 13 Jan 2015 19:44:37 -0500
Message-ID: <CAH8yC8=scFxjnxKLvzfaJ8qwp5-stXhX-6M7GagssjP7AzrGbw@mail.gmail.com>
From: Jeffrey Walton <noloader@gmail.com>
To: Chris Hartmann <cxhartmann@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/websec/5L1LhgqWJbj-GFkmZ8Q960NmXHk>
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] Authentic inter-domain relationships. Is this a security problem? Appropriate for websec?
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: noloader@gmail.com
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec/>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Jan 2015 00:44:41 -0000

> 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 <cxhartmann@gmail.com>; 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,
>