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
- [dmarc-ietf] PSD simplification Dave Crocker
- Re: [dmarc-ietf] PSD simplification Scott Kitterman
- Re: [dmarc-ietf] PSD simplification Dave Crocker
- Re: [dmarc-ietf] PSD simplification John Levine
- Re: [dmarc-ietf] PSD simplification Dave Crocker
- Re: [dmarc-ietf] PSD simplification John R Levine
- Re: [dmarc-ietf] PSD simplification Dave Crocker
- Re: [dmarc-ietf] PSD simplification John R Levine
- Re: [dmarc-ietf] PSD simplification Scott Kitterman
- Re: [dmarc-ietf] PSD simplification Dave Crocker
- Re: [dmarc-ietf] PSD simplification Scott Kitterman
- Re: [dmarc-ietf] PSD simplification Dave Crocker
- Re: [dmarc-ietf] PSD simplification Kurt Andersen (b)
- Re: [dmarc-ietf] PSD simplification Dave Crocker
- Re: [dmarc-ietf] PSD simplification John Levine
- Re: [dmarc-ietf] PSD simplification Scott Kitterman
- Re: [dmarc-ietf] PSD simplification John Levine
- Re: [dmarc-ietf] PSD simplification Scott Kitterman
- Re: [dmarc-ietf] PSD simplification Dave Crocker
- Re: [dmarc-ietf] PSD simplification Alessandro Vesely
- Re: [dmarc-ietf] PSD simplification Scott Kitterman
- Re: [dmarc-ietf] PSD simplification Scott Kitterman