Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

Scott Kitterman <sklist@kitterman.com> Wed, 17 July 2019 05:40 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 00C6D120148 for <dmarc@ietfa.amsl.com>; Tue, 16 Jul 2019 22:40:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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=8GvSH3cG; dkim=pass (2048-bit key) header.d=kitterman.com header.b=MLs2CX1P
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 XCLoLjYtAjk1 for <dmarc@ietfa.amsl.com>; Tue, 16 Jul 2019 22:40:14 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ABF812006B for <dmarc@ietf.org>; Tue, 16 Jul 2019 22:40:14 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id 74F37F80045 for <dmarc@ietf.org>; Wed, 17 Jul 2019 01:39:43 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1563341983; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=UZ8ZYFeL6wXtxMD9CFt4YIsUlwM0zTnFCahIhUGVnsw=; b=8GvSH3cGy6WwKS9JD1Oo7540NTzHgn7ybIDBsPUvhCOQa6xMLCbgcBqK ccJGEIlmzTX6Ntst1FLBYtiaP8fyAw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1563341983; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=UZ8ZYFeL6wXtxMD9CFt4YIsUlwM0zTnFCahIhUGVnsw=; b=MLs2CX1PpO08L/vg+/OsVIJMoXs3dSlfAP354SWmj30a8f3OB1L/Y/fX OE5OsMcrVzoTpzAvNqz6Mgk9SsltHfsTD4IlHAiswOPf+FGAjE0GCvku0K yt4Obt7ipJ8UvZR3QGJQlQ2htHsDykbArFKpQ+x2gM9p/vzDDzR/o+pAOS mil3Jxq72XK5C0WX+FayJQ0bzxmhbWCjIQAjBDGT1R7ALmyvSffImjvlwf pd2TIDA3nmN8HsrB65FaabL82U4phUo4LtQhrBYCN642GpgEZjfIIMx9GF WXP4/jOgJkQmvu5exh8ZIUG+yrEktwTElxHHl1NomMbsdwNnii0M2w==
Received: from l5580.localnet (unknown [IPv6:2600:380:4a72:99c3:ca:14c:24f3:8d22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 139AAF80042 for <dmarc@ietf.org>; Wed, 17 Jul 2019 01:39:42 -0400 (EDT)
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
Date: Wed, 17 Jul 2019 01:39:41 -0400
Message-ID: <1692123.ljdY5SVR4M@l5580>
In-Reply-To: <CAD2i3WN42v0RHzu+2=+_mjX5kmxw6B-0F3-=bY-bTEsJM1qLvA@mail.gmail.com>
References: <CAL0qLwbbz_UhBLsURg=eXhRBC2g9OghiN==T9Uq9pFuLtd=b7w@mail.gmail.com> <1808303.aIhlromXIS@l5580> <CAD2i3WN42v0RHzu+2=+_mjX5kmxw6B-0F3-=bY-bTEsJM1qLvA@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/m-7KQnzBbwXi0rYVu9v9u_a2pws>
Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
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: Wed, 17 Jul 2019 05:40:16 -0000

On Wednesday, July 17, 2019 1:18:50 AM EDT Seth Blank wrote:
> As an individual-
> 
> On Tue, Jul 16, 2019 at 10:05 PM Scott Kitterman <sklist@kitterman.com>;
> 
> wrote:
> > Although a few people have suggested this, I think it would be a mistake
> > because it would cause a gratuitous incompatibility with RFC 7468.
> 
> The people suggesting this are the people asking for np= in the first place.
> > I think it is a desirable characteristic that the addition of np not
> > disturb
> > existing expectations.  If a recipient that is a participant in the
> > experiment
> > attempts to determine policy for a sub-domain without 'np', then the
> > result
> > should match what a non-participant gets.
> 
> I'm not certain this is desirable for PSD in the context of an experiment
> around np=.
> 
> Specifically, the point of np= is for strict enforcement for non-existent
> domains while the remainder of the zone gets its act together moving
> registered domains to policies more strict than none. Since, a) nearly all
> sp= policies in the world are set to "none", and b) sp= is meaningless at
> the PSD level anyway, I concur that np= should default to p=.
> 
> Or put a different way, the tags serve very different use cases, and in the
> wild, sp= will generally be none, whereas np= will generally be
> reject/quarantine. p= is the the meaningful tie-breaker here at the PSD
> level if no np= is set.
> 
> This (np='s default) should also be called out as part of the experiment
> around np if the group doesn't reach consensus before WGLC ends tomorrow.

Let's be clear:  If the experiment around 'np' is successful and it is 
included in a future non-experimental update, then it will have enough 
deployment that changing its behavior will almost certainly fall into the too 
hard bucket without an amazingly good reason.  While the experiment may 
conclude 'np' isn't worth doing, I think we should assume that if it is 
carried forward, then it will be the way we define it in this document.  So, 
"It's an experiment" is not, in my view, a useful reason to accept 
interoperability issues we can avoid.

I think you are reading the request backwards.

Yes, the point of 'np' is to allow for a stricter sub-domain policy, but 
that's to support early deployment of strict PSD level policies without 
breaking org domains that are still deploying/have not deployed DMARC.

Case:

PSO mandates all orgs deploy DMARC, but that's not done yet.  PSO wants to 
deploy PSD DMARC for reject at the PSD level and for non-existent domains, but 
leave non-DMARC deployed existing domains at none.  PSO publishes these 
policieis for the PSD:

p=reject, sp=none, np=reject

Results (for org domains)

Org domain with DMARC: Use org policy
Org domain with no DMARC:
         Regular DMARC: No DMARC policy, no feedback
         PSD DMARC receiver: policy is none, feedback to PSO if requested
Non-existent domain:
         Regular DMARC: No DMARC policy, no feedback
         PSD DMARC receiver: policy is reject, feedback to PSO if requested

Having 'np' fall back to 'p' doesn't actually solve the problem you claim to 
be solving since it only affects non-implementers.

I believe that's the exact requested case and the changeset I've provided 
supports that without creating a situation where every implementer of the 
experiment suddenly starts processing existing DMARC records differently (which 
I think would be very bad).

Scott K