Re: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot's review of the DMARC spec)

Steve Jones <steven.m.jones@gmail.com> Mon, 08 July 2013 21:04 UTC

Return-Path: <steven.m.jones@gmail.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7648621F9E34 for <dmarc@ietfa.amsl.com>; Mon, 8 Jul 2013 14:04:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wN8Sctze84Yh for <dmarc@ietfa.amsl.com>; Mon, 8 Jul 2013 14:04:54 -0700 (PDT)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id ABE1F21F9E2D for <dmarc@ietf.org>; Mon, 8 Jul 2013 14:04:52 -0700 (PDT)
Received: by mail-ie0-f174.google.com with SMTP id 9so10937449iec.19 for <dmarc@ietf.org>; Mon, 08 Jul 2013 14:04:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LZmWGGbE9jFkbqIeYEDDMsio8MhNBq3comjxRCipxRs=; b=F4kkYa69O5u4vEhoEkDZvTDwSyZm5w+2nd60zvDgvEFECznxJlWwHwAOzLE/w/+LdK OCwXVQQOcWHf7psAzkbx7whf6gPNT4CJSNbbr7+HyUqZma64PB5Q5GrmWTAj6MXp6TPv 2Dgv6HTyJ0E7ATYtkEosCwTqEduZrv7CNoNrCPYIJYQ8NqauiFaV0MV/N/XiXmuC0JlJ AQ6e6CTYv8LTNAHRwehwaCVTZOy82gS+Bd/fSVG7Ua3fqf5VH7tDE2eYIwaJ/xWXU2C7 pohC69W76vAjzZ8LTDOhGjsVFI4dz8KJfgcBRbMIqjCCH0MnLPUznUyUqe6RyYXmgFkk J/OQ==
MIME-Version: 1.0
X-Received: by 10.50.13.72 with SMTP id f8mr4394316igc.53.1373317492089; Mon, 08 Jul 2013 14:04:52 -0700 (PDT)
Received: by 10.50.127.200 with HTTP; Mon, 8 Jul 2013 14:04:51 -0700 (PDT)
In-Reply-To: <CE39F90A45FF0C49A1EA229FC9899B056E8F6B@USCLES544.agna.amgreetings.com>
References: <51D864EC.1040105@gmail.com> <CDFDB559.A9994%zwicky@yahoo-inc.com> <CE39F90A45FF0C49A1EA229FC9899B056E8F6B@USCLES544.agna.amgreetings.com>
Date: Mon, 08 Jul 2013 14:04:51 -0700
Message-ID: <CAESBpdBM5pnE34XVdiH7d1APhCdxtvhaOo0nKmVdwAR_BzJFZw@mail.gmail.com>
From: Steve Jones <steven.m.jones@gmail.com>
To: "MH Michael Hammer (5304)" <MHammer@ag.com>
Content-Type: multipart/alternative; boundary="089e013c65de47abe004e10665fb"
Cc: Dave Crocker <dcrocker@gmail.com>, Matt Simerson <matt@tnpi.net>, Eliot Lear <lear@cisco.com>, "dmarc@ietf.org" <dmarc@ietf.org>, "Murray S. Kucherawy" <superuser@gmail.com>, SM <sm@resistor.net>, Elizabeth Zwicky <zwicky@yahoo-inc.com>
Subject: Re: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot's review of the DMARC spec)
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmarc>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Jul 2013 21:04:55 -0000

Do we have other definitions to cover deceptive names not similar to an
existing domain? If phishers are using CraftsmanOnline.com, and Sears using
other domains, is that a cousin domain or do we need a different term?

If it is considered a cousin domain because it plays on a known entity name
or brand identity...

<t hangText="Cousin Domain:"> A domain name that is
     deceptively similar to a registered domain name or other name
     associated with a known entity.  The target name may be familiar to
     many users, thereby imparting a degree of trust. The deceptive
similarity can
     trick the user by embedding the essential parts of the target name
     in a new string (such as, "companysecurity.example" to attack
     "company.example"); it can use some variant of the target name,
     such as replacing 'i' with '1', which is known as a "homograph
     attack;" or it may invent a plausible domain name based on the
     common name of a known entity or brand, such as "BrandAOnline.example,"
     where the entity actually uses other domain names such as
     "xyzcorp.example."
</t>


On Mon, Jul 8, 2013 at 5:54 AM, MH Michael Hammer (5304) <MHammer@ag.com>wrote:

> I don't think it is just that the target domain is familiar to the users
> under attack. It is the "brand identity". That is, the users under attack
> may be familiar with the brand but not necessarily familiar with the exact
> domain that the brand/organization uses.
>
> Mike
>
> > -----Original Message-----
> > From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf
> > Of Elizabeth Zwicky
> > Sent: Saturday, July 06, 2013 2:52 PM
> > To: Dave Crocker; Matt Simerson
> > Cc: SM; dmarc@ietf.org; Murray S. Kucherawy; Eliot Lear
> > Subject: Re: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot's
> > review of the DMARC spec)
> >
> >
> > I would say that the target domain is familiar to the users under attack.
> >
> >       Elizabeth
> >
> > On 7/6/13 11:41 AM, "Dave Crocker" <dcrocker@gmail.com> wrote:
> >
> > >Thanks for the quick feedback.
> > >
> > >some additional thoughts...
> > >
> > >
> > >On 7/6/2013 11:18 AM, Matt Simerson wrote:
> > >>>     A cousin domain is a registered domain name that is deceptively
> > >>> similar to a target domain name.  The target domain is *usually
> > >>> *familiar to many end-users, and therefore imparts a degree of trust.
> > >>>  The deceptive similarity can trick the user by embedding the
> > >>> essential parts of the target name, in a new string, or it can use
> > >>> some variant of the target name, such as replacing 'i' with '1'.
> > >>
> > >> I inserted the word 'usually'.
> > >
> > >That's a kind of careful phrasing that makes sense for precise
> > >specification, but I think is actually distracting for the usage here.
> > >
> > >That is, I think that extra qualifiers in definitions are, ummmm...
> > >usually distracting...
> > >
> > >It's not that it's wrong; it's that I doubt it's as helpful as we'd
> like.
> > >
> > >
> > >> In addition to providing basic examples, perhaps include the well
> > >> defined and recognized terms: typosquatting, and IDN homographs?
> > >>
> > >> https://en.wikipedia.org/wiki/Typosquatting
> > >> https://en.wikipedia.org/wiki/IDN_homograph_attack
> > >
> > >yeah, and probably cite the dhs.gov text, to show some history to the
> > >key phrase.
> > >
> > >d/
> > >
> > >
> > >--
> > >Dave Crocker
> > >Brandenburg InternetWorking
> > >bbiw.net
> > >_______________________________________________
> > >dmarc mailing list
> > >dmarc@ietf.org
> > >https://www.ietf.org/mailman/listinfo/dmarc
> >
> > _______________________________________________
> > dmarc mailing list
> > dmarc@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmarc
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>