Re: [dmarc-ietf] Rethinking DMARC for PSDs

Scott Kitterman <sklist@kitterman.com> Tue, 09 April 2019 00:37 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 4F356120162 for <dmarc@ietfa.amsl.com>; Mon, 8 Apr 2019 17:37:56 -0700 (PDT)
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, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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=GlYETMyE; dkim=pass (2048-bit key) header.d=kitterman.com header.b=Q5Hse2P4
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 hK0oeESk0ahp for <dmarc@ietfa.amsl.com>; Mon, 8 Apr 2019 17:37:54 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1603B12014D for <dmarc@ietf.org>; Mon, 8 Apr 2019 17:37:54 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 27C9BF80920; Mon, 8 Apr 2019 20:37:53 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1554770272; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=LPw/tv3BFolt3cd8ASY3NyW5zzJwVuIb6wpKnvmTiew=; b=GlYETMyEgn+mqXdrHhoEcrf3DPDTv8avRXeFRRzv7tbUbikZkyEt8mGQ 94AmC/k8bE+GEr5WKQJPbDiXNJXFCQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1554770272; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=LPw/tv3BFolt3cd8ASY3NyW5zzJwVuIb6wpKnvmTiew=; b=Q5Hse2P4xgSvAN3eYIuY2h/UKhfG77H1v4I9HY+10BmIJ2046b7Pe5eM gXKS3gLLC1RYNNXvcXz4VS1HghIEHThOJVIOb+uwrgImUUjpfg5km8aEcr 8DktpVV206BAoz+h3Z7aHPXf/q/Nwc5VhZJwSajEKbslZhwSXgpsB8fOUk FgiCo0NNOe+O2sOHzCyRBgZ+8NrepnFl5jcL+TI+kVoq582qGyWS30Oi8u dRGYAlEBsQ9PLzIDuTlKvBbgOBfZoho/Lxo8TEMQJttfumBRuHZ/7epRg3 aK9cZPCsyWvbNmWCb267TsdH2N0Ab75bqZjjw4Q3tpqjEOhFvwrpOQ==
Received: from [10.82.211.29] (mobile-166-170-31-60.mycingular.net [166.170.31.60]) by interserver.kitterman.com (Postfix) with ESMTPSA id 99F36F807D4; Mon, 8 Apr 2019 20:37:52 -0400 (EDT)
Date: Tue, 09 Apr 2019 00:37:51 +0000
In-Reply-To: <3e3a5997f71544f1a29fca8845fcbf60@bayviewphysicians.com>
References: <08252783d22443e79b707537df97c872@bayviewphysicians.com> <CABuGu1qdU4TbL3okQnNMn6yr+xODFfBG6o9ZOwJ1SgdjGJ95nA@mail.gmail.com> <08693A61-D3AD-448D-B64C-B36262756C65@kitterman.com> <3e3a5997f71544f1a29fca8845fcbf60@bayviewphysicians.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: <7EFE60BD-0EBB-431D-AC6B-C63383ECDFD0@kitterman.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/8r4iLh4J00ljZdirFNEqROSbvmg>
Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs
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: Tue, 09 Apr 2019 00:37:56 -0000

No, I think you seriously misunderstand what the IETF does.  It doesn't do product specifications, it does interoperability specifications.

This is seriously off-topic for the DMARC working group list anyway.

Scott K
P.S. There are open source components to accomplish all the requirements you listed, some assembly required.  Discussion though should happen somewhere else.

On April 9, 2019 12:27:06 AM UTC, "Douglas E. Foster" <fosterd@bayviewphysicians.com> wrote:
>Scott, you misunderstand what this type of standard would look like.  
>It 
>would defines Use Cases that the device should address, with some 
>acknowledgement to the tradeoffs between perceived risk and perceived 
>difficulty of implementation. 
>   
>Implementation suggestions may be part of the use case.  It would be
>hard 
>to implement SPF-like capability without using SPF data, but there are
>many 
>ways that SPF data could be utilized.   
>  
>There are also fundamental security principles that everyone should be 
>following.   
>	"Trusted communication (whitelist) should not occur until and unless
>the 
>identity of the correspondent is confirmed."
>	  	Escalation of privilege (in this context, bypassing integrity
>tests) 
>should be limited to the minimum necessary set of privileges to achieve
>the 
>business requirement. 
> Mr. O'Driscoll's comments seemed to make the same mistake.   The 
>configuration of email defenses will be different between a residential
>
>ISP, a large bank, and the US Army.   However, the principles and use
>cases 
>will be similar because any threat actor could take aim at any target. 
> 
>What differs is the perceived risk and the perceived complications from
>
>mitigating the risk, matched to each organizatoin's tolerance for risk.
>  
> Nothing in this standard could be an absolute mandate, because only 
>government has the legal authority to say "This product cannot be sold
>for 
>purpose X because it does not have feature Y,"   It could say, "You
>must 
>implement this feature to claim compliance with RFC xxxx"   This type
>of 
>standard can and would pressure vendors to move in the right direction.
> It 
>would also help purchases know how to be more intelligent shoppers. 
>  
> There is plenty of difficulty in reaching a consensus statement on 
>something like this, not least because each vendor wants to look 
>acceptable, no matter how inferior his current product may be.   Just 
>because a topic is difficult does not mean there is no reason to
>discuss 
>it.   Working Groups exist because these issues take time and effort to
>
>flesh out.   It is hard to argue that spam-getting-through is not an 
>important topic, but I suppose some people may try to do so.
>  
>
>  
>  
>
>----------------------------------------
> From: "Scott Kitterman" <sklist@kitterman.com>
>Sent: Monday, April 8, 2019 7:13 PM
>To: dmarc@ietf.org
>Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs   
>
>On April 8, 2019 11:08:30 PM UTC, "Kurt Andersen (b)"
><kboth@drkurt.com> 
>wrote:
>>On Mon, Apr 8, 2019 at 3:55 PM Douglas E. Foster <
>>fosterd@bayviewphysicians.com> wrote:
>>
>>> I don't know how to express my shock at today's conversations. One
>>of
>>> the shocks comes from this:
>>>
>>> We have consensus that the better email filters do not need the
>DMARC
>>for
>>> PSDs standard, because they are already blocking non-existent
>>domains.
>>>
>>
>>This neglects the benefit to the domain operators of receiving the
>>reports
>>about abuse of their domain space. For the end recipient of the bogus
>>traffic, there is no difference.
>>
>>
>>> The inferior email filters are not expected to implement this
>>feature,
>>> because they are inferior products.
>>>
>>
>>Somewhat tautological, but most likely true.
>>
>>
>>> Therefore the new standard has no expected benefit, but we need to
>>finish
>>> it anyway.
>>>
>>
>>Incorrect - see my first point.
>
>The entire thing is further premised on the false premise that because
>two 
>small mail operators find one filtering technique appropriate for their
>
>situation and scale, anyone that has a different design is inferior.
>
>Scott K
>
>_______________________________________________
>dmarc mailing list
>dmarc@ietf.org
>https://www.ietf.org/mailman/listinfo/dmarc
>