Re: [dmarc-ietf] PSD simplification

Scott Kitterman <> Fri, 14 December 2018 00:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B29D4130EC2 for <>; Thu, 13 Dec 2018 16:25:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
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: (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.b=P9NpVPlR; dkim=pass (2048-bit key) header.b=BAh8Qe1I
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w9uN0GWs_Q1S for <>; Thu, 13 Dec 2018 16:25:27 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DAF611286E7 for <>; Thu, 13 Dec 2018 16:25:26 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=201812e; t=1544747124; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=vELgs3M+Ongx0skFnXJByUovF04atl4s8KrBvxBzvnA=; b=P9NpVPlRjJt8I0ZORzWMd19eKJ/aegHaM00MqVDCtbh0GSjRwJtdjIuD cHxwXXs2xxb/m33LswyCzVjRegAnCw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=201812r; t=1544747123; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=vELgs3M+Ongx0skFnXJByUovF04atl4s8KrBvxBzvnA=; b=BAh8Qe1IH6YEXlph5/V0CmYwfO+Gq6tH7nFqWXs2cfP0/xfSsG0ZK64G 1Rn+xStimu6Si0d6dARviCdkqIf38ljhmzqfjxWialIIAOB4eX5db4vVgB HAUfz1Xtaadu1qolu9pN4lBu4KqOPgvwAvBON/HuYTCYYfgakabcPfH3+Y of64W81Qo7qxOQwVemXk6DWrV/k/aqrINi+RoPcx9H3j/OZmfj70v263Bh sZIFR6RDgYl4UTnIRo71DO/aeoOn/Sxa3mwjUMh7fVWxQi2JK6LsbpgBci dsViNrwaiKR8qTumdod2rEsC3pp5mFOTYDyzR449NOYTsaJ+LJtKFw==
Received: from kitterma-e6430.localnet ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id E3A682D4062B for <>; Thu, 13 Dec 2018 18:25:23 -0600 (CST)
From: Scott Kitterman <>
Date: Thu, 13 Dec 2018 19:25:22 -0500
Message-ID: <2046741.GJeexbxHFF@kitterma-e6430>
User-Agent: KMail/4.13.3 (Linux/3.13.0-163-generic; KDE/4.13.3; x86_64; ; )
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <>
Subject: Re: [dmarc-ietf] PSD simplification
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Dec 2018 00:25:29 -0000

On Thursday, December 13, 2018 08:24:38 AM Dave Crocker wrote:
> On 12/13/2018 8:20 AM, Kurt Andersen (b) wrote:
> > A link to inscrutable legalese, potentially in a non-interpretable
> > format (consider, for example, a PDF consisting of images of a foreign
> > alphabet - perhaps Klingon) doesn't seem to really achieve the intent.
> > And neither does the bald assertion - "trust me, I require people to do
> > the right thing" :-)
> And yet the current draft relies on a single 'expert' to be able to
> achieve a productive outcome with exactly the same material.  And it
> produces only a single review at the time of registration.
> The benefit of the approach I'm suggesting is that it surfaces these
> documents much more openly and makes it likely they will be reviewed
> much more widely and on a continuing basis.

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.  

In previous examples, this has been analogized  to the Verisign sitefinder 
debacle.  Personally, I think it's worse.  Without an external check, this is 
a tool for enhancing the surveillance capacity of authoritarian regimes.  I 
don't find making the documents public so people can complain at all useful.  
The entities that will most want to use this will tend to be the ones that 
care least about complaints.

I'm not claiming an IANA registry is an essential part of the solution, I'm 
sure their are better ideas, it's just the one I thought of.  What we need is 
some location of information about domains that is neutrally managed in 
accordance with open processes.  That sounded like IANA to me, but I'm open to 

Scott K