IETF Logo Mail Archive

Re: [dmarc-ietf] Lookup Limitations For Public Suffix Domains

Scott Kitterman <sklist@kitterman.com> Sat, 01 December 2018 01:28 UTC

Return-Path: <sklist@kitterman.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 6DA8C130DC4 for <dmarc@ietfa.amsl.com>; Fri, 30 Nov 2018 17:28:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=JKWzHwDl; dkim=pass (2048-bit key) header.d=kitterman.com header.b=kvizbBqC
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 rEuWoaHvD50x for <dmarc@ietfa.amsl.com>; Fri, 30 Nov 2018 17:28:08 -0800 (PST)
Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F5E612D7F8 for <dmarc@ietf.org>; Fri, 30 Nov 2018 17:28:08 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1543627686; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=RxZiidTYSL+hVLqA4m5ePC0gx44953unT+xUHy8iXfg=; b=JKWzHwDlCPde0OwsEUBrmXQcTRKQaoZxHZ6QbOcrMOl4iqqktIGK+bZH T8M/KnauQoenHfR/BKok/Zl5tPepDg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1543627686; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=RxZiidTYSL+hVLqA4m5ePC0gx44953unT+xUHy8iXfg=; b=kvizbBqCsxADcd2DSC5EV0c/aMTEVUzLs1J2UksoQYjMhD/jFIeAcHCS nOX9OGvwhssGi+UjXHrf/ypRNFnjzVffUsBlNfpMv0Zned5LbBdCxX6jVQ SSpD6ojl+mXpwQ4qj3elBNi6O2le6F+50GRf316J1ZHQbZAc4GzMtM68Mg Elk4VdYLRXjXNcz8AmIZBR02KaqTSzYa0/6wCjt77f0blwKHE6aCwSvzOo 2Dcha9p9gR5ADX18qPhydH5os8z1TPZ2q/6FIIWtoTFUYeTMDYI4y0P81r FHtlhBrzs6DRlZi5XALkE03Qm9LPJg9uB7pEq+oEVGPG3tUhHcnSzw==
Received: from [10.20.2.67] (mobile-166-170-35-7.mycingular.net [166.170.35.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id E9ADFC40190; Fri, 30 Nov 2018 19:28:05 -0600 (CST)
Date: Sat, 01 Dec 2018 01:27:54 +0000
In-Reply-To: <CADyWQ+ECVcmGMaxNgwL6a+j8dR4LcTNJMMS7G8ufOiataZULuQ@mail.gmail.com>
References: <20181201003301.1DFFA200915FC3@ary.qy> <6368515.cyHHj4lf58@kitterma-e6430> <CADyWQ+ECVcmGMaxNgwL6a+j8dR4LcTNJMMS7G8ufOiataZULuQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
To: dmarc@ietf.org
From: Scott Kitterman <sklist@kitterman.com>
Message-ID: <6D01ADF1-A11F-4FB1-9978-A50FEA5E2B0E@kitterman.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/E1Pk1RYoaaejWicLbKCyIHyckqU>
Subject: Re: [dmarc-ietf] Lookup Limitations For Public Suffix Domains
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 01 Dec 2018 01:28:11 -0000

Thanks.  That refreshes my memory.

I think it's a proposal that has potential to be an eventual standardized replacement for using the public suffix and we should look into publishing a DMARC specific variation.

It doesn't, however, seem to address the issue described in the draft's privacy considerations.

Perhaps we need to step back and see if there is consensus that the privacy considerations in the draft are substantially correct and if risk mitigation is needed as described.

Scott K

On December 1, 2018 1:06:17 AM UTC, Tim Wicinski <tjw.ietf@gmail.com> wrote:
>https://www.ietf.org/archive/id/draft-levine-dbound-dns-01.txt
>
>
>
>On Fri, Nov 30, 2018 at 8:04 PM Scott Kitterman <sklist@kitterman.com>
>wrote:
>
>> On Friday, November 30, 2018 07:33:00 PM John Levine wrote:
>> > In article <3881693.rR9BVk4Dlq@kitterma-e6430> you write:
>> > >2.  Externalize signaling about PSD participation.  As discussed
>in the
>> > >Privacy Considerations (section 4.1), we were concerned about the
>> privacy
>> > >implications of feedback on organizational domain traffic for
>> > >organizational domains that don't participate in DMARC being
>> > >inappropriately captured by public suffix operators.
>> >
>> > It seems to me this horse left the barn a long time ago.  Mail
>systems
>> > routinely check domains in HELO and in MAIL FROM against DNSBLs,
>which
>> > is at least as loggy as anything a DNS version of this check will
>do.
>> >
>> > Also, if you really want to keep people from logging your queries,
>you
>> > can set up a local mirror of the DNS zone, and update it in the
>usual
>> > way with AXFR and IXFR.  Whatever one might have in mind for a text
>> > version of this, a binary AXFR would be about as fast and IXFR of
>just
>> > the occasional change faster.
>> >
>> > Take a look at my DBOUND proposal.  I think it would be just the
>> > ticket for this application.
>>
>> I've lost track.  Which draft was that?
>>
>> I don't agree that a situation being bad is a reasonable reason not
>to try
>> and
>> keep it from getting worse.  I think the implications of the DMARC
>> feedback
>> reports are greater than logging queries.
>>
>> Scott K
>>
>> _______________________________________________
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>

v2.23.0 | Report a Bug | By Email