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

Alessandro Vesely <vesely@tana.it> Thu, 15 August 2019 10:20 UTC

Return-Path: <vesely@tana.it>
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 DE475120094 for <dmarc@ietfa.amsl.com>; Thu, 15 Aug 2019 03:20:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 sXB0lqYhzolO for <dmarc@ietfa.amsl.com>; Thu, 15 Aug 2019 03:20:18 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46184120072 for <dmarc@ietf.org>; Thu, 15 Aug 2019 03:20:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1565864415; bh=NZwk4AXoXA+42wdiz6OQffO9xMje+L74qw9zp6bRm3M=; l=3429; h=To:References:From:Date:In-Reply-To; b=DVyciW3kgV9P1EgA3/J2FAABA3i1xlRgkLsTS9Z2MfpFIuX9FaxjltYnwOTz8juCe eC/vWr1nGLRPNo7hwhRVjhKckfz1tip+6HnyYvC0N9Yx1SCcBQ3mzo6QE49wZSsnZ7 rEORkfeA+FUZ+gI2ERjx5062P7ti0azTWYN983XBhmk5n7WGzmMSvhhkLgUUW
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [192.168.1.100] ([5.170.70.68]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1.2, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC042.000000005D5531DE.0000501D; Thu, 15 Aug 2019 12:20:14 +0200
To: dmarc@ietf.org
References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com>
From: Alessandro Vesely <vesely@tana.it>
Openpgp: preference=signencrypt
Message-ID: <cf505fc8-b3d5-73c1-61da-bab319b669eb@tana.it>
Date: Thu, 15 Aug 2019 12:20:11 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/t3D0dNa5e_h6HsdDsvEX8IohoGs>
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, 15 Aug 2019 10:20:20 -0000

On Wed 14/Aug/2019 04:01:59 +0200 Dave Crocker wrote:
> 
> 
> Review of:    DMARC (Domain-based Message Authentication, Reporting, and
>               Conformance) Extension For PSDs (Public Suffix Domains)
> I-D:          draft-ietf-dmarc-psd-06
> Reviewer:     D. Crocker
> Review Date:  12 August 2019


I like very much Dave's prose, especially the background.  I hope
large fragments of it will make their way to either the PSD draft or
the reviewed DMARC spec itself.

For brevity, however, I only quote the passages I comment on:


> This approach is problematic in several ways.
> 
> It is a substantial increase in DMARC's operational overhead.  It adds
> a query that will often be needed -- especially in the face of limited
> DMARC adoption.  If a domain is not already a 'popular' DMARC
> reference -- that is, frequently encountered by the querying site --
> it is likely that there will be no DMARC record for any of the three
> needed queries. That means a 50% increase from two (failed) DNS
> queries to three (failed) queries.


That's actually a bit better.  After the second (failed) query, the
receiver consults the "augmented PSD".  IMHO, the latter should be a
local lookup, just like the PSD itself.  The third query is only
issued if the prefix matches.  Then, the likelihood that it fails is
very low.


> Arguably for DMARC purposes, an association domain can be treated the
> same as an organization domain, since the scope of the domain's
> authority over its sub-domains is an internal matter, to be determined
> by its agreements with association members.
> 
> What this means is that the real requirement here is to improve the
> mechanism for identifying the organizational domain, and that
> requirement is outside of DMARC.  This does not reduce the necessity
> of identifying these domains; rather it moves the task to where it
> belongs: This requires modification to the public suffix list
> operation, possibly with a parallel "private TLD" registry.


Right.  However, consulting the augmented PSD still has to be done in
two steps, the first one to give the organizational domain a chance to
override the association domain policy, the second step if no override
was published.

Let me add that the relevant case is NXDOMAIN.  For existing domains,
the association can see if a lazy organization misses a record and
force them to comply.  However inconsiderately, the association could
even publish itself a txt record at _dmarc\.lazy.example.  The
annoyance is trying wildcards to cover any non-existent domain name.


> An added benefit to this alternate view is that it eliminates the
> privacy concern about the draft specification:  only upper-level
> domains operating as organizational domains will be able to publish a
> domain-wide DMARC policy record.  Domains that really are classic
> public suffixes won't be able to.


Certainly, A.bank and B.bank shall not be conflated as far as
exchanging cookies and access rights is concerned, so a fine-grained
PSD will continue to exist.

I'm not sure flattening that structure for DMARC is a benefit.  By
skipping the second query, we'd deny organizations the possibility to
have subdomain email addresses like manager@branch.A.bank, unless
branch.A.bank either replicates or overrides the DMARC record of A.bank.




Best
Ale
--