Re: [dmarc-ietf] PSD simplification

Dave Crocker <dcrocker@gmail.com> Thu, 13 December 2018 16:08 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 07E9C12D4E9 for <dmarc@ietfa.amsl.com>; Thu, 13 Dec 2018 08:08:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, TVD_PH_BODY_META_ALL=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 LBf0an62MgQv for <dmarc@ietfa.amsl.com>; Thu, 13 Dec 2018 08:08:52 -0800 (PST)
Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDEC71277CC for <dmarc@ietf.org>; Thu, 13 Dec 2018 08:08:52 -0800 (PST)
Received: by mail-oi1-x230.google.com with SMTP id v6so2056038oif.2 for <dmarc@ietf.org>; Thu, 13 Dec 2018 08:08:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=dMmqDY90n/V6uMif8nlsd+R7JbNlc/IDOE9s8Bs1+vQ=; b=MFWlv3tLmUzsqlaWzFOD+Lfu+NdLgiPtczev4f7nVSJht5XFt963OHtVmEg3YPDsFV il4vrLcq+thQz/mpPrZj7eFgXMvD6uwxxKwWFWMkJxUKvl/demf2qdqT/xwXKZENnky3 onX9+o/yG8rly2ixusBdKvan7r7HzHNhwfL3XVvD47FlBOkIgqkXb3nRJ2pf5xc/JUFV h+Hg2ok6r/i/8mysIdTaSX3f6fpsxwM+J8PpTu2SZCZXUSlzVfrmhKm/pN/qd+nxAic4 mAJaOV88uX9REN1oDbEBJ5i39QqxzJZdcBYIPOiN/sjIabXwTMc68EmOjGHsbu+wEoFx 0t+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=dMmqDY90n/V6uMif8nlsd+R7JbNlc/IDOE9s8Bs1+vQ=; b=I18zB4uL2lZMoG+Q550HnUpGU1iqYz9zsDIOStLwx6zTZ+sG/l1yPi/Lor1vlpLS1/ yN1G4HG6fGl7pq2z9iYegVmM7HI09NbACAXCxSd+/VUB1IPMKilsbr/kqzL+bKsAaJQu EqWFuZ3ONU/oqKfGVFjuXydRTamHlibk1oLszEuI0rANrcMU2a9MX1MYXTjIyYkNdpcn jsKMoV3vWm0diPKwnyDAwie3iYKn0jPWsXun9ccuZuz6oETqCHkmSHwCSUsqxEbr50L/ FrEBZW2IHzaDGms4Lx3MPug9M6RGpcYMgEtox/0wV93jhtR5zUe483av1rpu+j1pFVIk vWKQ==
X-Gm-Message-State: AA+aEWY2R2J/ZPvV1PLeh06Pzfa46g41EMozfkHrmkvAIP+ZmA/CM+cS gmMHbMgroyBvdsByFUA+I/aNJ+DZ6W4=
X-Google-Smtp-Source: AFSGD/WpFSmi+Hsp1vqEWv1Eq408J6cYLGZ3PMG3RF3mWNEDNgu998U51e/Hp16n8XABJGjgeK7+zg==
X-Received: by 2002:aca:195:: with SMTP id 143mr3012274oib.322.1544717331511; Thu, 13 Dec 2018 08:08:51 -0800 (PST)
Received: from ?IPv6:2600:1700:a3a0:870:d167:e3f8:4e3c:c340? ([2600:1700:a3a0:870:d167:e3f8:4e3c:c340]) by smtp.gmail.com with ESMTPSA id g64sm1009312otb.77.2018.12.13.08.08.49 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 13 Dec 2018 08:08:50 -0800 (PST)
To: Scott Kitterman <sklist@kitterman.com>, dmarc@ietf.org
References: <b3ab712a-74b3-d580-65bc-a97bf8c4652d@gmail.com> <B64DD715-DFC4-42E1-87FC-15A5ED0B83F9@kitterman.com> <4e253157-3397-b901-4c1d-132c709b996e@gmail.com> <2657505.cCtalkmY2s@kitterma-e6430>
From: Dave Crocker <dcrocker@gmail.com>
Message-ID: <2981238b-1e41-294c-0c04-0b8183c7234e@gmail.com>
Date: Thu, 13 Dec 2018 08:08:46 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3
MIME-Version: 1.0
In-Reply-To: <2657505.cCtalkmY2s@kitterma-e6430>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/n3gI8xcfycCdoPjWJ08TJgiL5ys>
Subject: Re: [dmarc-ietf] PSD simplification
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, 13 Dec 2018 16:08:55 -0000

On 12/12/2018 8:21 PM, Scott Kitterman wrote:
> If we extend DMARC with PSD and no limitations on PSO
> participation, then those considerations will apply to every domain that does
> not participate in DMARC (because the PSO can now get the data


Scott,

Thanks for the clarification.

Now I understand the nature of the privacy concern:

      (Public) registries that publish a DMARC record will get email
      traffic reports of their customers who do not publish DMARC
      records.

This does indeed seem a new attack surface, since the other powers of 
the registry mostly fall under denial of service rather than traffic 
analysis.

So the provisions of Section 6.1 in the -psd draft are meant to ensure 
that entries in the PSD registry are limited to any registry that:

>    adequately describes PSD policy to require domain owners to use DMARC
>    or that all domain owners are part of a single organization with the
>    PSO.

I suspect that this will have cases that prove rather more challenging 
to the Expert Reviewer than one might expect -- definition of 'single 
organization' can get sticky in some cases -- but still, the nature of 
the requirement is clear:  ensure that registry policy is documented and 
targets DMARC usage explicitly.

(Small point: Given this purpose for the registry, it's probably 
important for the registry's policy document to be publicly available, 
but that's not stated as required.)


Hmmm...

Let me suggest a much easier hack, which differs in utility mostly by 
being post hoc rather than the current draft's pre-hoc mechanism:

      Require the registry to publish another DNS record, in its _dmarc 
node, which a) asserts either than DMARC is required or that the subtree 
is part of a single organization, and b) contain a URL to the 
documentation for this.

A query for the DMARC record of the registry will also deliver this 
information record.  (This might be the first case in which the problem 
of getting 'other' TXT records is actually a feature and not a problem...)

That makes the information public, while avoiding the considerable 
overhead and problems of a new registry -- nevermind one that needs 
real-time querying.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net