Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
Dotzero <dotzero@gmail.com> Fri, 19 July 2019 12:04 UTC
Return-Path: <dotzero@gmail.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 5FA05120089 for <dmarc@ietfa.amsl.com>; Fri, 19 Jul 2019 05:04:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 dIf2Rrxy3qNv for <dmarc@ietfa.amsl.com>; Fri, 19 Jul 2019 05:04:34 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFE0F120019 for <dmarc@ietf.org>; Fri, 19 Jul 2019 05:04:33 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id y4so32036010wrm.2 for <dmarc@ietf.org>; Fri, 19 Jul 2019 05:04:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7XToM1EPxSERtMO8b+M9t4J/eZofKEqBYGhp9xykCpw=; b=l3PBVWtdIgJ32tyFdyepRfngRJmZtem3lusL7URZ6Uj2/s1hm5Jbp3Jcxgv73nvw5x FHo3B+wdrRCHJhehhC0K6KKBjcTDAhs5DuYZzZLNuqZ3t7ygJpLWwW2XjUKD10/YvsZC VI77dc1RkpFgv/+WwI31PmxxE6XScSwUFoip33bdjS//GiYAKcO6CHE4x7fyZoct0epZ 2zjx8hwDazEIpE+29xdHNx9c9J0cBALzCWZBca+eWC4u1mZC6crcg+JjctTqEKK45sJi OUoEPzYo9nSpG+OtIy2JPbY5j1kOoH1Ea5Y2tl9MOS3LuKE/ZEs4u7m75E2jMY3JJtjZ dbzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7XToM1EPxSERtMO8b+M9t4J/eZofKEqBYGhp9xykCpw=; b=Ubg32yMzG+JgND6WkxflAOuungxuEEJRSBceNg4qpoSNDsBWfQR4+E2WuqCEOlzRlE avqep7g/WxtvXkOdARkpkoL4uLGBer8d1bEg6j137T6drAPPSolU08JjQDOzM8LCmsrb hY2HXTx+iq1GGF57lTuYuItj5dfktqousUxg9hQqy7lEXGNv3Wfb1tpW/UXuSy1CxhXH PNYPv6W6kOFRduL1DaHN+LI/JR5UkM6Pnk8AvFmq13j/LxATPZdmNsHALg2aAVI5einO Ha1/GEob/LijvKIg741UILbyAV2Ha1t/ZIIPvt1Axwq1czoKJ2LxPIfGiGX9eRFUl317 DBDg==
X-Gm-Message-State: APjAAAWKBHz2eIxmNJIa0q7jvpxKdibACW0MbeiqD+YYU6PeDYs0/Wkg 2sL75/JZx9WwhjbssAANdnhs2vQePg3DePB6Op7rng==
X-Google-Smtp-Source: APXvYqwHoSzOS+DDK63Uabhj0QX0USzfOc23uH0wrMvTX8qQtJwE7Oh4xq3Yk+B/gy7imRsFxNqZnXj4lmRbdqX+OxU=
X-Received: by 2002:a5d:4484:: with SMTP id j4mr56280342wrq.143.1563537872336; Fri, 19 Jul 2019 05:04:32 -0700 (PDT)
MIME-Version: 1.0
References: <CAL0qLwbbz_UhBLsURg=eXhRBC2g9OghiN==T9Uq9pFuLtd=b7w@mail.gmail.com> <4249121.lBB2AW0kmB@l5580> <CABuGu1qGJq2fes9B1vwb1v=JMi3HcydvzDvoi0+ZrEwC4rYk1A@mail.gmail.com> <3280991.vD5HP6B0ME@l5580> <LO2P123MB2285D18172BC95D42A968B1CC9CB0@LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM>
In-Reply-To: <LO2P123MB2285D18172BC95D42A968B1CC9CB0@LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM>
From: Dotzero <dotzero@gmail.com>
Date: Fri, 19 Jul 2019 08:04:20 -0400
Message-ID: <CAJ4XoYc2tMoLebD-qiau7-aB3Lo0m0k3JB6tg0b-FN7yTif4jw@mail.gmail.com>
To: Ian Levy <ian.levy=40ncsc.gov.uk@dmarc.ietf.org>
Cc: Scott Kitterman <sklist@kitterman.com>, "dmarc@ietf.org" <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000793cb9058e07874a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/9iekSiCqjj5IRfnOiOMtQ-vBWUE>
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: Fri, 19 Jul 2019 12:04:37 -0000
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. Just a few thoughts. Michael Hammer
- [dmarc-ietf] Working Group Last Call: draft-ietf-… Murray S. Kucherawy
- Re: [dmarc-ietf] Working Group Last Call: draft-i… Seth Blank
- Re: [dmarc-ietf] Working Group Last Call: draft-i… Seth Blank
- Re: [dmarc-ietf] Working Group Last Call: draft-i… Kurt Andersen (b)
- Re: [dmarc-ietf] Working Group Last Call: draft-i… Scott Kitterman
- Re: [dmarc-ietf] Working Group Last Call: draft-i… Alessandro Vesely
- Re: [dmarc-ietf] Working Group Last Call: draft-i… Hollenbeck, Scott
- Re: [dmarc-ietf] Working Group Last Call: draft-i… John Levine
- Re: [dmarc-ietf] Working Group Last Call: draft-i… Scott Kitterman
- [dmarc-ietf] Introduction context was: Re: Workin… Scott Kitterman
- Re: [dmarc-ietf] Working Group Last Call: draft-i… Scott Kitterman
- Re: [dmarc-ietf] Introduction context was: Re: Wo… Hollenbeck, Scott
- Re: [dmarc-ietf] Introduction context was: Re: Wo… Scott Kitterman
- [dmarc-ietf] Mention ICANN/operational limitation… Scott Kitterman
- [dmarc-ietf] Nonexistent Domain Policy was: Re: W… Scott Kitterman
- [dmarc-ietf] Implemnetations was: Re: Working Gro… Scott Kitterman
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Kurt Andersen (b)
- Re: [dmarc-ietf] Mention ICANN/operational limita… Stan Kalisch
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Seth Blank
- Re: [dmarc-ietf] Mention ICANN/operational limita… Dotzero
- Re: [dmarc-ietf] Mention ICANN/operational limita… Scott Kitterman
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Scott Kitterman
- Re: [dmarc-ietf] Mention ICANN/operational limita… Hollenbeck, Scott
- Re: [dmarc-ietf] Mention ICANN/operational limita… Stan Kalisch
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… John Levine
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Dotzero
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Scott Kitterman
- Re: [dmarc-ietf] Introduction context was: Re: Wo… Scott Kitterman
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… John Levine
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Scott Kitterman
- Re: [dmarc-ietf] Mention ICANN/operational limita… Alessandro Vesely
- Re: [dmarc-ietf] Working Group Last Call: draft-i… Alessandro Vesely
- Re: [dmarc-ietf] Mention ICANN/operational limita… Scott Kitterman
- Re: [dmarc-ietf] Working Group Last Call: draft-i… Scott Kitterman
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Scott Kitterman
- Re: [dmarc-ietf] Mention ICANN/operational limita… Alessandro Vesely
- Re: [dmarc-ietf] Working Group Last Call: draft-i… Alessandro Vesely
- Re: [dmarc-ietf] Mention ICANN/operational limita… Tim Wicinski
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Ian Levy
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Tim Wicinski
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Richard C
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Alessandro Vesely
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Chudow, Eric B CIV NSA DSAW (USA)
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Ian Levy
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Scott Kitterman
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Scott Kitterman
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Scott Kitterman
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Scott Kitterman
- Re: [dmarc-ietf] Working Group Last Call: draft-i… Scott Kitterman
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Seth Blank
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Scott Kitterman
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Seth Blank
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Scott Kitterman
- Re: [dmarc-ietf] Working Group Last Call: draft-i… Murray S. Kucherawy
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Tim Wicinski
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Chudow, Eric B CIV NSA DSAW (USA)
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Kurt Andersen (b)
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… John Levine
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Kurt Andersen (b)
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Scott Kitterman
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Scott Kitterman
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Kurt Andersen (b)
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Scott Kitterman
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Ian Levy
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Dotzero
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Kurt Andersen (b)
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Kurt Andersen (b)
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Scott Kitterman
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Scott Kitterman
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Tim Wicinski
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Scott Kitterman
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Scott Kitterman
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Scott Kitterman
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… John Levine
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Ian Levy
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Alessandro Vesely
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Scott Kitterman
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Alessandro Vesely
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Scott Kitterman
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Douglas E. Foster
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Scott Kitterman
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Dotzero
- Re: [dmarc-ietf] Nonexistent Domain Policy was: R… Kurt Andersen