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:04 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 A3E66120125 for <dmarc@ietfa.amsl.com>; Tue, 16 Jul 2019 22:04:53 -0700 (PDT)
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=ayBDe6Kq; dkim=pass (2048-bit key) header.d=kitterman.com header.b=ZrO1iwA2
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 RuYh71xQ6JnN for <dmarc@ietfa.amsl.com>; Tue, 16 Jul 2019 22:04:52 -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 DD7501200B7 for <dmarc@ietf.org>; Tue, 16 Jul 2019 22:04:51 -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 01A78F805B5 for <dmarc@ietf.org>; Wed, 17 Jul 2019 01:04:51 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1563339890; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=sVrczwhtEkuHvh5XEwrzwYEV3L7TY4bazdcemkivVv0=; b=ayBDe6Kqa3tYwFfNCCTWaiS4LjKEYUvP/ML/WzA3MnpCJWM7LuVqI+Ih jtHsZGQpu6jLar1Pe1KvPeyZJrjIAA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1563339890; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=sVrczwhtEkuHvh5XEwrzwYEV3L7TY4bazdcemkivVv0=; b=ZrO1iwA2N3oDpEQ70J7Ayog5GMawHdhI0Ol7on6t1MxVf6lIx3JVhJwG ndKRqmTjjiRs+ETCxnW8x16z1T73sFgpcjsdjXpGVn4SHnzFObl79C9dAp AcZIBVBDkEWWNhi0ObL6zVCvnGUC0+kLPwlwZL9TGtyU1xfv/6fVadEebS TD/bSnzePqdoQk2mhEPFWHAtik35vmq08MuxbeDLe+2oF25I8jidnenFfe VmEZtf7o5KgmiqBvDjopq8u0R8Xyl8Q0KQ1+Bf8QW4qLIjkF/afS+nlgTS JQ0jBEuwZ/knaGi8y4ijYRmiZ2ro1scUYEkA6H310rLa7Kdu+5Lnng==
Received: from l5580.localnet (unknown [IPv6:2600:380:4a72:99c3:ca:14c:24f3:8d22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 77BE5F8008C for <dmarc@ietf.org>; Wed, 17 Jul 2019 01:04:50 -0400 (EDT)
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
Date: Wed, 17 Jul 2019 01:00:47 -0400
Message-ID: <1808303.aIhlromXIS@l5580>
In-Reply-To: <553D43C8D961C14BB27C614AC48FC0311CAA91FE@UMECHPA7D.easf.csd.disa.mil>
References: <CAL0qLwbbz_UhBLsURg=eXhRBC2g9OghiN==T9Uq9pFuLtd=b7w@mail.gmail.com> <4789054.Ip9ilXyiH0@l5580> <553D43C8D961C14BB27C614AC48FC0311CAA91FE@UMECHPA7D.easf.csd.disa.mil>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/1DVGfitZGiNo_2ciQfFCHURDkcc>
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:04:54 -0000

On Tuesday, July 16, 2019 12:14:54 PM EDT Chudow, Eric B CIV NSA DSAW (USA) 
wrote:
> I recently joined this working group from the United States Department of
> Defense (DoD), which runs the .mil TLD. We appreciate all the work that has
> been done so far on DMARC and are currently investing significant efforts
> to implement DMARC broadly across DoD domains.  We value and support this
> PSD DMARC draft and experiment and see how it will complement the existing
> DMARC effort for us and many others by being able to broadly apply DMARC at
> TLDs and PSDs when subdomains are missing their own DMARC records and for
> non-existent subdomains, which are significant gaps today.
> 
> 
> 
> I agree with the suggestion below that the default policy for non-existent
> sub-domains should be the domain's policy if the "np" tag is absent, rather
> than defaulting to the "sp" tag's policy.

Although a few people have suggested this, I think it would be a mistake 
because it would cause a gratuitous incompatibility with RFC 7468.

Current behavior (where np is not defined) is for sp to apply to all domains, 
existing or not.  No distinction is made.  Consider the effect of the two 
different approaches:

Example:

p=reject
sp=none
np=quarantine

A receiver that is not a participant in the experiment will process the policy 
for a non-existent subdomain as none (since they don't recognize np).

This is equivalent to:

p=reject
sp=none

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.

If no 'np' falls back to 'p', then the policy is reject, which will  have a 
negative interaction with non-participants.  If the policy falls back to 'sp', 
then the result is the same whether the recipient is a participant or not.

Also, keep in mind, that if 'sp' is not present, it falls back to 'p', so 
falling back to 'sp' first is not a dead end.

> 
> A few minor suggestions:
> 
> 
> 
> In section 4, "requiremetns" should be "requirements".

Fixed.  Thanks.

> In section 4.1, there is an extra "be", so "This leakage could be
> potentially be utilized ..." should be "This leakage could potentially be
> utilized ....".

Fixed.  Thanks.

> In appendix B, "faciliate" should be "facilitate".

Fixed.  Thanks,
...

Scott K