Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

Scott Kitterman <sklist@kitterman.com> Thu, 05 September 2019 13:36 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 1AA431200CD for <dmarc@ietfa.amsl.com>; Thu, 5 Sep 2019 06:36:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=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=pBFFBHRz; dkim=pass (2048-bit key) header.d=kitterman.com header.b=FNcoyxnv
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 9Zz1oQPZGTFh for <dmarc@ietfa.amsl.com>; Thu, 5 Sep 2019 06:36:04 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EF87120026 for <dmarc@ietf.org>; Thu, 5 Sep 2019 06:36:04 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id D08F0F8066A; Thu, 5 Sep 2019 09:35:32 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1567690532; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=fjnmWVqzvehF1o63CMmnkQP1x8n4c84y/uda7qgCOQQ=; b=pBFFBHRzPYJnoemLrAsigFT8t8vc4xvKVQXYyNbYQNFGOy2a1tk/uOsC e3vPneiRCUrzyaOX312zu+nojkUXCw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1567690532; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=fjnmWVqzvehF1o63CMmnkQP1x8n4c84y/uda7qgCOQQ=; b=FNcoyxnvLYl4Xu8vqMkI6MtPcm9gBMB43A60jdVQCNdDQtKYskJjDvX+ XrNIaw0nAYwI7HbwqSdYW+0U6s85soMlcJXpFAq2m7J+Y3qOtSFpWgFH7/ age+mjeT1mVpzo7l+dOlfGa9XzOlAv1g7RcksTS4Nt8k25NOhbdEx9CKDU LMJAlkX+mrzcmT8la24zeu8iO5AIgD4uzWk4D/mtuQEL6ZWW8ZN98gvWnW c2OUMUEV6PO66y5avkMVYhwyl6r0Zvfx50etWpW+fRNfdl51u0ORJvFWCc hGTaccKfYu2ZBSHegWy/Z2Ae9Se9nffWgmyHKmxK5hinWZ2PvdOdCg==
Received: from [10.226.138.197] (mobile-166-171-120-109.mycingular.net [166.171.120.109]) by interserver.kitterman.com (Postfix) with ESMTPSA id 50DE6F80284; Thu, 5 Sep 2019 09:35:32 -0400 (EDT)
Date: Thu, 05 Sep 2019 13:35:29 +0000
In-Reply-To: <3d886a18-7dc2-2c7a-4d0a-8c1ae0bfb4c5@tana.it>
References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <CAL0qLwacbAT04tckpPcRcnOt=1QByOBeJ7uDf6rNK6NRwtxZYg@mail.gmail.com> <51219bbd-3785-e6bb-414a-bd564b6c856d@gmail.com> <2922527.kgd3cNqxNO@l5580> <3d886a18-7dc2-2c7a-4d0a-8c1ae0bfb4c5@tana.it>
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: <7788EC9D-D4F7-4B00-863D-7289E8B2AB41@kitterman.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/6pC8b2Cr1CqtNIXHTeeB12qptT8>
Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
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: Thu, 05 Sep 2019 13:36:07 -0000


On September 5, 2019 8:28:05 AM UTC, Alessandro Vesely <vesely@tana.it> wrote:
>On Thu 05/Sep/2019 07:15:35 +0200 Scott Kitterman wrote:
>> On Wednesday, September 4, 2019 9:28:41 AM EDT Dave Crocker wrote:
>>> On 9/3/2019 8:57 AM, Murray S. Kucherawy wrote:
>>>> 
>>>> construction of an augmented PSL (i.e., the actual PSL coupled with
>the
>>>> queryable registry described in Appendix B), which DMARC then can
>>>> consume to resolve the use cases that have appeared which now need
>to be
>>>> addressed.  The portion of the experiment comprising an
>augmentation to
>>>> DMARC’s algorithm would therefore not be part of DMARC permanently.
>>>> Then, if the experiment proves effective, that would become prima
>facie
>>>> evidence that the PSL, augmented with this additional information,
>would
>>>> enable DMARC to resolve those use cases.  Such an augmented PSL
>would
>>>> still conform to the desirable separation of functions to which you
>>>> alluded.
>>> 
>>> With respect to the use of this work as a model for changes to the
>PSL,
>>> unfortunately the spec is not written in a fashion to support that.
>>> This really is a core concern, in my view: the work needs to have a
>>> basic model that really is expected to be appropriate for the long
>term;
>>> hence my suggestion to highly limit any changes to DMARC and,
>instead,
>>> cast the bulk of the work as augmenting the PSL.
>>> 
>>> That said, and as for getting changes to the PSL, based on my
>>> interactions with that community, I think it unlikely.  There does
>not
>>> seem to be the interest or resources for such work.  Strategically,
>>> that's the biggest hurdle to overcome, IMO.
>>> 
>>> ..
>>> 
>>> Hence my current view that:
>>> 
>>> 1. The change to DMARC should be limited to permitting the query for
>the
>>> organization domain to be anywhere in the DNS tree, including a TLD.
>>> Within DMARC this would not look like 'extra' mechanism.
>>> 
>>> 2. The mechanism that processes that query should be cast strictly
>as a
>>> PSL enhancement, independent of DMARC.
>> 
>> I think some related, but distinct issues are conflated in your
>analysis.
>> 
>> The core PSD check doesn't need a PSL change.  The current PSL works
>fine.  The 
>> sequence is:
>> 
>> 1.  Check at the From domain level.
>> 2.  If no record, check at the org level.
>> 3.  [New] if no record check one level above the org level (PSD).
>> 
>> That's all doable with the current PSL.  I don't think we want to
>force 
>> additional lookups between 1 and 2 for lower level domains. 
>Currently for 
>> something like:
>> 
>> a.b.c.d.org.example where only example is in the PSL the queries
>would be:
>> 
>> 1.   a.b.c.d.org.example
>> 2.   org.example
>> 3.   example
>> 
>> As I read your proposal we've have to add in queries for:
>> 
>> b.c.d.org.example
>> c.d.org.example
>> d.org.example
>> 
>> I don't think querying anywhere in the DNS treee is an improvement
>for 
>> scalability of DMARC.
>
>
>Besides scalability, the question is whether b, c, or d have the right
>to
>override the DMARC policy of org.example.  The current spec clearly
>says no.
>
>My reading of Dave's proposal differs.  Modifying the PSL has the
>implicit
>objective to skip step 2.  That is, to limit queries to:
>
>1.   a.b.c.d.org.example
>3.   example
>
>Thereby slashing org.example's privilege to establish its own domain
>policy.
>
>
>> Adding the single additional PSD lookup works fine with the existing
>PSL.  
>> There are two reasons to go beyond this:
>> 
>> 1.  Since most PSDs won't publish DMARC records, as an efficiency,
>let's not do 
>> that third lookup unless we have to.
>> 
>> 2.  PSD DMARC without some constraints on the additional lookup
>automatically 
>> opts in all organizational domains that do not publish DMARC records,
>which 
>> has privacy implications.  This is discussed in Section 4.1 of the
>draft.
>
>
>We should also consider updates:
>
>How often is/should be the PSL updated at average mail servers?
>
>How often would then the extra list at psddmarc.org have to be updated?
>
>
>> As it says at the start of Appendix B, the options proposed there are
>to 
>> mitigate the privacy risks described in Section 4.1.  The related
>requirements 
>> discussion is in Appendix A, Section A.1.
>> 
>> It is a beneficial side effect that they also reduce the need for DNS
>lookups 
>> and thus provide an efficiency enhancement.
>> 
>> If we didn't care about privacy, this would be easy.  That's the hard
>part 
>> that does not have a clear solution.  One thing that is clear is that
>it's not 
>> the PSL.  PSL is a collector of assertions from operators, so it
>fails to meet 
>> the attributes laid out in A.1.
>
>
>Failure reports are considerably less implemented than aggregate ones. 
>The
>current spec doesn't mention any privacy risk in its Security
>Considerations
>section.  However, some concern must exist, otherwise the difference in
>implementations cannot be easily explained.  The I-D at hand touches on
>this
>point marginally.  A general consideration would better fit in
>DMARCbis.

That's because there's an entire separate section on privacy considerations.

Scott K