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