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

Scott Kitterman <sklist@kitterman.com> Sat, 20 July 2019 03:15 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 64E561200E7 for <dmarc@ietfa.amsl.com>; Fri, 19 Jul 2019 20:15:39 -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=Kmoz8cTK; dkim=pass (2048-bit key) header.d=kitterman.com header.b=NFOSi0rl
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 dvl7rB7HkwUz for <dmarc@ietfa.amsl.com>; Fri, 19 Jul 2019 20:15:37 -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 9455C12004E for <dmarc@ietf.org>; Fri, 19 Jul 2019 20:15:37 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id E2534F80499 for <dmarc@ietf.org>; Fri, 19 Jul 2019 23:15:06 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1563592506; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=LG1oAzbOicY3NSY8WKn0KqxmHWk0gCGXoC00NP3Mou4=; b=Kmoz8cTKTC95Wo+eeYuW8KGT1MpG+x2/n25OjxzHMyH6SS3QBiTaszEs 9AX1pbCMzC7z6LRIwUl0gUVDdihiCg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1563592506; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=LG1oAzbOicY3NSY8WKn0KqxmHWk0gCGXoC00NP3Mou4=; b=NFOSi0rlkOo1kvaeAbyB88WCwO3D3KLKcTRRdEv3sYmXwfX2r9UPZU/E 6NTK0r4RwKlm6LA9XvW9+H7xOfkeA9ZkjB3GuHHmB22Z3b8jQbIDcmFU/g Pnb8MPJ6efpeVrVYTsVDiQLkobnDTJeh4hu5Rcw38y3vgKBJ/qf90Pjp07 0oG+RcFT6tQcvG/wGzltnuaqdYS2St0aePL6QOy8nbc5ordaauiHDORfcB tRNGIPLg3gJffXKj46svYRI4Bj7ubEm+3HP4+tMVI3IzLhp5+IBy7Y6wDq 13UpAXVfbZAgr3S4IDojO2LYUhk4KfHbvy5Aqr8mCZ1CWR27HrxzwA==
Received: from l5580.localnet (wsip-68-224-171-140.sd.sd.cox.net [68.224.171.140]) by interserver.kitterman.com (Postfix) with ESMTPSA id 84255F80042 for <dmarc@ietf.org>; Fri, 19 Jul 2019 23:15:06 -0400 (EDT)
From: Scott Kitterman <sklist@kitterman.com>
To: "dmarc@ietf.org" <dmarc@ietf.org>
Date: Fri, 19 Jul 2019 23:15:04 -0400
Message-ID: <2333259.aoXCTIVaPC@l5580>
In-Reply-To: <CAJ4XoYc2tMoLebD-qiau7-aB3Lo0m0k3JB6tg0b-FN7yTif4jw@mail.gmail.com>
References: <CAL0qLwbbz_UhBLsURg=eXhRBC2g9OghiN==T9Uq9pFuLtd=b7w@mail.gmail.com> <LO2P123MB2285D18172BC95D42A968B1CC9CB0@LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM> <CAJ4XoYc2tMoLebD-qiau7-aB3Lo0m0k3JB6tg0b-FN7yTif4jw@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/O3iNiZyp0zRvrwvjAuFlbOpFv44>
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: Sat, 20 Jul 2019 03:15:40 -0000

On Friday, July 19, 2019 8:04:20 AM EDT Dotzero wrote:
> I've been following the discussion but haven't contributed anything until
> this point. Comment below.
> 
> On Fri, Jul 19, 2019 at 3:29 AM Ian Levy <ian.levy=
> 
> 40ncsc.gov.uk@dmarc.ietf.org>; wrote:
> > > I think this is one of those "you must be this tall to ride on this
> > > ride"
> > > situations.  DNS comes equipped with multiple footguns and you have to
> > 
> > know a bit about what you're doing to make sure you get the effects you're
> > after.
> > 
> > This. DMARC today allows people to disconnect their outgoing mail from the
> > rest of the world. Admittedly, the PSD-level policies would have a much
> > greater effect, but your PSD/TLD operator can already bork you if they're
> > not competent.
> > There are two different buckets of risk in my view, though :
> > 1) New TLDs are effectively greenfield sites and can enforce appropriate
> > requirements on their customers from the start to minimize the chance of
> > unintended consequences (for example, by requiring domain DMARC labels).
> > 2) Existing TLDs, where there are many subdomains with wildly variable
> > implementations, policies and use and here we are going to have to be
> > really careful. Careful and methodical testing will be necessary to make
> > sure that introduction of the PSD-level policies doesn't break anything
> > important. It took us 6 months to get to synthesizing p=reject for
> > non-existent subdomains of .gov.uk. A lot of that was analysing the data
> > we got back and fixing stuff that we never expected (like Kerberos - don't
> > ask!). I don't see why it would be different with the np= tag, but it will
> > hopefully be much more limited in what we could mess up.
> > 
> > I think we're really all worried about the second of these cases. If
> > that's true, then I'm with Scott - if you don't understand this stuff,
> > don't go and set an np tag on your PSD and cross your fingers. It's going
> > to end badly. One of the things about doing the experiment is surely to
> > help us understand how badly these can go wrong, so we can write down a
> > bunch of ways not to do things.
> > 
> > We can write in the document that scissors are sharp and running with
> > sharp things can cause problems. But in the end, someone is going to run
> > with scissors and get hurt. We can't code for every single case here and
> > we
> > surely must assume a level of competence of people implementing something
> > like this.
> 
> The problem, which we know or should know, is that DNS records are
> apparently difficult to get right. We have a large corpus of data points to
> back this up based on decades of experience. Even large, supposedly
> experienced and technically qualified organizations shoot themselves in the
> foot. Speaking as an original participant in the dmarc.org team, I can't
> emphasize enough the education and evangelization effort involved related
> to adoption (and misunderstanding of how it works... or doesn't work).
> 
> I think you are incorrect with your assumption regarding scenario #1. I
> recently had a discussion with an owner/operator of a number of "new" TLDs.
> They have no clue regarding this effort. So even if a TLD is new, that does
> not mean it will implement from day 1. This means scenario #2 is more
> likely the scenario to be dealt with (default) rather than #1. Perhaps
> after some extended period of pain or if ICANN mandates something, #1 will
> become the default, but I wouldn't hold my breath.
> 
> With regard to scenario #2, it is not enough to simply say "don't run with
> scissors". Some group, M3AAWG or ICANN or ISOC, will need to educate and
> evangelize those outside the inner circle, so to speak. I'm sure that
> companies like Agari, Dmarcian, Valimail, etc. will gladly provide
> assistance., That TLD owner/operator I mentioned earlier is not overly
> familiar with the space or those vendors.
> 
> It is not enough for the creators of a proposed standard to state it's
> technical validity. This implies a deployment document based on the
> experiences of early adopters.

I agree, but I think solving that is outside the scope of the current 
document.

Scott K