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

Matt Simerson <matt@tnpi.net> Sat, 06 July 2013 18:19 UTC

Return-Path: <matt@tnpi.net>
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 C4D8D21F9CD1 for <dmarc@ietfa.amsl.com>; Sat, 6 Jul 2013 11:19:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 w5biSEjO5La1 for <dmarc@ietfa.amsl.com>; Sat, 6 Jul 2013 11:19:04 -0700 (PDT)
Received: from mail.theartfarm.com (mail.theartfarm.com [208.75.177.101]) by ietfa.amsl.com (Postfix) with ESMTP id A767821F9CD0 for <dmarc@ietf.org>; Sat, 6 Jul 2013 11:19:04 -0700 (PDT)
Received: (qmail 67997 invoked by uid 1026); 6 Jul 2013 18:18:58 -0000
Received: from c-76-121-98-64.hsd1.wa.comcast.net (HELO [10.0.1.32]) (76.121.98.64) by mail.theartfarm.com (qpsmtpd/0.93) with (AES128-SHA encrypted) ESMTPSA; Sat, 06 Jul 2013 14:18:58 -0400
Authentication-Results: mail.theartfarm.com; auth=pass (plain) smtp.auth=matt@theartfarm.com; iprev=pass
X-Virus-Checked: by ClamAV 0.97.8 on mail.theartfarm.com
X-Virus-Found: No
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=tnpi.net; h=content-type:mime-version:subject:from:in-reply-to:date:cc:message-id:references:to; s=mar2013; bh=9PN8GLhmGHEMG6qiYgyvf+4DH3LPN2Oq/nJTfNx5omc=; b=Pxi5r+nhUWHbzkkRuGDCKHogQHD95JDaqb7SmEQpXWMF1Sn2/gP/9wcMw3+Cd2LgR7Jx5KRvOAtqIE0TI5oSV7AKdlr68zsWht65Fj5VuowHr9+94TXBwhv5EcFMDImgvOUNX800ggYxBqmav4IaFxH6xIiNKOsqEScaw3kcgQ5UblAEUugnmzBPD1gSPwoqX8nvZmGt25G9Nnfm3+zPpQHGyt0+REbCN1FYsb0BJjocCjdI+FQTmYnLiv6sfTZJIgmD4ekwTFxCMUGFmVAczB5cPd7dPdSYgjKzlLo4Nx6Owria8m/tjJv+HAhRDYV+ovHeHqoLoKpaUGjU7RGByQ==
X-HELO: [10.0.1.32]
Content-Type: multipart/alternative; boundary="Apple-Mail=_740BB305-9476-43D9-9B9B-4877EB05694B"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Matt Simerson <matt@tnpi.net>
In-Reply-To: <51D858EB.3030202@gmail.com>
Date: Sat, 06 Jul 2013 11:18:57 -0700
Message-Id: <BD1F96A6-2D86-4FE7-89CC-E52CA32670D0@tnpi.net>
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> <51D858EB.3030202@gmail.com>
To: Dave Crocker <dcrocker@gmail.com>
X-Mailer: Apple Mail (2.1508)
Cc: SM <sm@resistor.net>, "dmarc@ietf.org" <dmarc@ietf.org>, "Murray S. Kucherawy" <superuser@gmail.com>, Eliot Lear <lear@cisco.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: Sat, 06 Jul 2013 18:19:08 -0000

On Jul 6, 2013, at 10:50 AM, Dave Crocker <dcrocker@gmail.com> wrote:

> 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.
> 
> IAnyhow, 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...

+1

> So in looking these over, I find myself liking the phrase "deceptively similar".

+1

> 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 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'. 

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

Matt