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

Dave Crocker <dcrocker@gmail.com> Sat, 06 July 2013 17:51 UTC

Return-Path: <dcrocker@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 464A721F9C85 for <dmarc@ietfa.amsl.com>; Sat, 6 Jul 2013 10:51:02 -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]
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 lANONuFR69je for <dmarc@ietfa.amsl.com>; Sat, 6 Jul 2013 10:51:01 -0700 (PDT)
Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id D159221F9B94 for <dmarc@ietf.org>; Sat, 6 Jul 2013 10:50:56 -0700 (PDT)
Received: by mail-oa0-f48.google.com with SMTP id f4so4626926oah.7 for <dmarc@ietf.org>; Sat, 06 Jul 2013 10:50:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Me+L9JqGG1Yhgos2QRzk84GNcq6HzZNc2smsB3JjPps=; b=kWcC1hJhhBnL6goEgyweVx2ryCvBEzFJwzPFE2frktuTMDiot+57F/7QfVePXDNrFe iOq9nEDBZGyC/FSXq+epOEHrDY5HJmUlan64l0b+35VqlV+JVYaXHqgilaPLhhB5+65y fCvxBwCR0OhQIXlgzgVEGVgcCKhzkBCgrxjbMeUK1uFTuL2Op/zLryhxddUKRXfgy80D ga51Sdwnutz+oaY9RT+we7olOqdifIEeCz39AnC+ix29D7LsEYqmNiD+Z5KfWORgqF/u L1zlQgv/jENqqgu3E34MbDfDgDE6Uxr4UPDlNDi++TUWu01x579njcTMQSJpCPW+In64 Ib5A==
X-Received: by 10.182.81.233 with SMTP id d9mr15917079oby.43.1373133056440; Sat, 06 Jul 2013 10:50:56 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id df11sm23967564oec.0.2013.07.06.10.50.54 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Jul 2013 10:50:55 -0700 (PDT)
Message-ID: <51D858EB.3030202@gmail.com>
Date: Sat, 06 Jul 2013 10:50:35 -0700
From: Dave Crocker <dcrocker@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: "Murray S. Kucherawy" <superuser@gmail.com>
References: <519B47DC.20008@cisco.com> <CAL0qLwYZOp1FNVSAmzXYkZG_O3Yv+EQrAKKLpRiE5svcOMamTA@mail.gmail.com> <6.2.5.6.2.20130523002139.0da7ac58@resistor.net> <CAL0qLwYT6BS=HGLX1-u80aqaJWefipT5tcg5Ut_549y4rOej9g@mail.gmail.com>
In-Reply-To: <CAL0qLwYT6BS=HGLX1-u80aqaJWefipT5tcg5Ut_549y4rOej9g@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: SM <sm@resistor.net>, "dmarc@ietf.org" <dmarc@ietf.org>, Eliot Lear <lear@cisco.com>
Subject: [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: Sat, 06 Jul 2013 17:51:02 -0000

On 7/5/2013 1:34 AM, Murray S. Kucherawy wrote:
> On Thu, May 23, 2013 at 2:55 AM, SM <sm@resistor.net
> <mailto:sm@resistor.net>> wrote:
>     The terminology section mentions terms such as "cousin domains",
>     "domain owner", etc.  Although such terms may be popular I don't
>     think that it is a good idea to use them in a protocol document as
>     they can be ambiguous.
>
>
> Can you make other suggestions?  I think the first one is not ambiguous
> in general, but we're very clear on defining and using the second.

I'm astonished to discover that google does not readily produce major 
listings of a definition of cousin domain. (Interestingly, the dmarc 
base draft showed up pretty high in the search...)

Anyhow, I think that means a) we have to create our own definition, and 
b) it's worth being fairly careful about the text of the definition, 
since there's a chance it will become popular...


First listing I found strikes me as logical but wholly inadequate, in 
terms of interesting attacks:

      http://www.informit.com/articles/article.aspx?p=1190114

      "we defined a cousin domain name as one that contains the 
candidate domain name in its entirety, with additional words either 
prefixed or appended to the candidate domain name."


A squib from the book gets the idea, but isn't quite sufficient as a 
'definition':

      Phishing and Countermeasures: Understanding the Increasing Problem
      of ...;  edited by Markus Jakobsson, Steven Myers

      "phisher regisers a domain name similar to the targeted domain, 
such as 'commerceflaw.com' instead of 'commerceflow.com'."

A variant of this one shows up in a dhs.gov document:

      http://www.cyber.st.dhs.gov/docs/phishing-dhs-report.pdf

      "domain name controlled by a phisher that isdeceptively similar to
       a legitimate domain name, such as
       www.commerceflowsecurity.cominstead of www.commerceflow.com."


So in looking these over, I find myself liking the phrase "deceptively 
similar".  Hence I'll propose:

      A cousin domain is a registered domain name that is deceptively 
similar to a target domain name.  The target domain is 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'.


d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net