Re: [dmarc-ietf] PSD simplification

Scott Kitterman <sklist@kitterman.com> Sat, 15 December 2018 01:23 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 58F07130EBA for <dmarc@ietfa.amsl.com>; Fri, 14 Dec 2018 17:23:43 -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=qY5lYeNt; dkim=pass (2048-bit key) header.d=kitterman.com header.b=ARqhrzdL
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 PcysmNtfA3Ip for <dmarc@ietfa.amsl.com>; Fri, 14 Dec 2018 17:23:41 -0800 (PST)
Received: from softlayer.kitterman.com (softlayer.kitterman.com [IPv6:2607:f0d0:3a01:a3::9]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B77F12E036 for <dmarc@ietf.org>; Fri, 14 Dec 2018 17:23:41 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1544837019; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=WW6HQUCW1PaCJYHL0l6A2fLkTIst1mx8eCd0adgHxUU=; b=qY5lYeNtwIyyB22jR7zzKsgPSziYropblQvC0qjTdneQYBYJ8YP+jT6x tCb5EQNr4zGHLWwyfgNtnPhi/A3VDA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1544837019; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=WW6HQUCW1PaCJYHL0l6A2fLkTIst1mx8eCd0adgHxUU=; b=ARqhrzdLLh6g6EjfCOMAoyUvRw6CVgkAmyWf7hrgK3wd4+j1r2kHfwaC 45aEc6hi2rfKRY4Vzfx3ZkSEo5OUFccC9qLdkBqjvhuBKlzXJfOAgMdJI7 ozXmSkr1v8I5DQrFA+YyPWMA5scnyaLS2P6AUjtS1yY4N52shzlENsZQtV igJitf5Zm20+sfBgDNkn2a8/8JSBbraQC1ErtBxnX4OsrDnTCot1QyyJDF HbX858d4jLvAjBpJ0VNBTIZTqgDI4XpJ45r5d2zd4hH1mgwghWOxkeGp6P vAUjxZOiOp8B1KvhbLqnlrY4nV8Gd95GgP1OqEbDzqDl9r5N40FraA==
Received: from [10.5.165.47] (mobile-166-171-56-58.mycingular.net [166.171.56.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id 531992D409A1; Fri, 14 Dec 2018 19:23:39 -0600 (CST)
Date: Sat, 15 Dec 2018 01:23:32 +0000
In-Reply-To: <ab6b0f8e-859a-a5c1-8605-4efacbbf99f1@gmail.com>
References: <b3ab712a-74b3-d580-65bc-a97bf8c4652d@gmail.com> <CABuGu1qtQE=eq5AS09koAz6yOr7QMCBy1Jq99Jgx_nNC6_iREA@mail.gmail.com> <f89e7365-2e37-f949-7438-1567368e3169@gmail.com> <2046741.GJeexbxHFF@kitterma-e6430> <ab6b0f8e-859a-a5c1-8605-4efacbbf99f1@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: <31F9BE79-4DE2-4A8B-BFAE-E5660419C279@kitterman.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/2D51u76Tr5a9YO_LOEuoPFWREWc>
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: Sat, 15 Dec 2018 01:23:44 -0000


On December 14, 2018 4:34:35 AM UTC, Dave Crocker <dcrocker@gmail.com> wrote:
>On 12/13/2018 4:25 PM, Scott Kitterman wrote:
>> It suffers from what is, in my opinion, a fatal flaw: it relies
>entirely on
>> assertions that any PSO can publish with no external review.  Without
>some
>> kind of third-party check on this, I don't believe there's any
>privacy
>> mitigation at all.
>
>
>I think that assessment is misses an essential point.
>
>Let me back up and say that my suggested alternative is intended to
>take 
>the basic concern you are raising seriously.  (I'm not stating a 
>personal opinion about the seriousness of this as a threat vector, but 
>merely looking for a simpler way to satisfy the concern.)
>
>The alternative requires that the registry's dmarc record be
>accompanied 
>by a record that points to the terms and conditions the registry 
>publishes to indicate why their record is acceptable.  (Your draft's 
>specification of those conditions looked to me like a reasonable 
>starting point; there should be a separate wg discussion for the
>precise 
>details and wording; I don't have a personal opinion about those
>words.)
>
>As for the benefits I see in the alternative I've proposed, I'll class 
>them as simplification and robustness.
>
>First, a new, query-able registry is expensive to run; and difficult to
>
>ensure quality control for, over the long run.
>
>Second, the vetting method your draft proposes for the registry relies 
>on a technical expert to make what is frankly a legal assessment of the
>
>terms and conditions that the registry publishes.  And that assessment 
>is made only one time, when the registry entry is first created.  The 
>registry might change its T&C text and we'd be unaware of it.
>
>So while you are technically correct that the alternative means that
>the 
>registry gets to /publish/ with no external review, it is not true that
>their dmarc record will automatically be used without review.
>
>In fact what I'm proposing will make widespread and ongoing review 
>likely, IMO, probably in the spirit of ongoing reputation assessment 
>that the email industry already does, although for dmarc default record
>rather than spam.

I see your point.  In addition to complexity, tohe issue that there is no mechanism for removing bad actors from the registry does present a problem.

Let me think it over and see if I can come up with text that both addresses your concerns and also provides guidance that I'd be comfortable with in lieu of the registry.

Scott K