[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
- [dmarc-ietf] Fwd: Eliot's review of the DMARC spec Murray S. Kucherawy
- Re: [dmarc-ietf] Fwd: Eliot's review of the DMARC… SM
- Re: [dmarc-ietf] Fwd: Eliot's review of the DMARC… John Levine
- Re: [dmarc-ietf] Eliot's review of the DMARC spec Tim Draegen
- Re: [dmarc-ietf] Fwd: Eliot's review of the DMARC… Matt Simerson
- Re: [dmarc-ietf] Fwd: Eliot's review of the DMARC… John R Levine
- Re: [dmarc-ietf] Eliot's review of the DMARC spec Murray S. Kucherawy
- Re: [dmarc-ietf] Fwd: Eliot's review of the DMARC… Murray S. Kucherawy
- Re: [dmarc-ietf] Eliot's review of the DMARC spec Eliot Lear
- Re: [dmarc-ietf] Eliot's review of the DMARC spec John Levine
- Re: [dmarc-ietf] Eliot's review of the DMARC spec Murray S. Kucherawy
- [dmarc-ietf] Review of draft-kucherawy-dmarc-base… SM
- Re: [dmarc-ietf] Eliot's review of the DMARC spec John R Levine
- Re: [dmarc-ietf] Review of draft-kucherawy-dmarc-… Franck Martin
- [dmarc-ietf] cousin domain definition (was Re: Fw… Dave Crocker
- Re: [dmarc-ietf] Review of draft-kucherawy-dmarc-… SM
- Re: [dmarc-ietf] cousin domain definition (was Re… Matt Simerson
- Re: [dmarc-ietf] cousin domain definition (was Re… Dave Crocker
- Re: [dmarc-ietf] cousin domain definition (was Re… Elizabeth Zwicky
- Re: [dmarc-ietf] cousin domain definition (was Re… Matt Simerson
- Re: [dmarc-ietf] Review of draft-kucherawy-dmarc-… Franck Martin
- Re: [dmarc-ietf] cousin domain definition (was Re… Franck Martin
- Re: [dmarc-ietf] cousin domain definition (was Re… Dave Crocker
- Re: [dmarc-ietf] cousin domain definition (was Re… John Levine
- Re: [dmarc-ietf] cousin domain definition (was Re… Murray S. Kucherawy
- Re: [dmarc-ietf] Review of draft-kucherawy-dmarc-… SM
- Re: [dmarc-ietf] Review of draft-kucherawy-dmarc-… Murray S. Kucherawy
- Re: [dmarc-ietf] cousin domain definition (was Re… Murray S. Kucherawy
- Re: [dmarc-ietf] cousin domain definition (was Re… Matt Simerson
- Re: [dmarc-ietf] cousin domain definition (was Re… Matt Simerson
- Re: [dmarc-ietf] cousin domain definition (was Re… Dave Crocker
- Re: [dmarc-ietf] cousin domain definition (was Re… MH Michael Hammer (5304)
- Re: [dmarc-ietf] cousin domain definition (was Re… Steve Jones
- Re: [dmarc-ietf] cousin domain definition (was Re… Barry Leiba
- Re: [dmarc-ietf] cousin domain definition (was Re… Scott Kitterman
- Re: [dmarc-ietf] cousin domain definition (was Re… Steve Jones
- Re: [dmarc-ietf] cousin domain definition (was Re… Matt Simerson