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

Ian Levy <ian.levy@ncsc.gov.uk> Sat, 20 July 2019 09:05 UTC

Return-Path: <ian.levy@ncsc.gov.uk>
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 77FBC120134 for <dmarc@ietfa.amsl.com>; Sat, 20 Jul 2019 02:05:03 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ncsc.gov.uk
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 KleRhleUv2AU for <dmarc@ietfa.amsl.com>; Sat, 20 Jul 2019 02:05:00 -0700 (PDT)
Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100122.outbound.protection.outlook.com [40.107.10.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02081120058 for <dmarc@ietf.org>; Sat, 20 Jul 2019 02:04:59 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BynThPBcOZvIkAtVqVpLieWzLe+isfvFyFnX2Yshv+9qtIwdoV/wbNjaCgi7Cjlp2BBTR2feStbVciNcG/HEOga4wUTff2E3QCpFMd9qs9ZvU54FukxwVKu9FPusouMhe7oi517zrINK+35ZlBzpfFno1be61tNJJ0YRF7gZG/7ROaBc3mNyf1t5yvS+KhQZ/htPUY7zfsrnDQq+FFvHRGjWlQWQvzUho3I2MDb08bD9z9jrvo9EzOXq+7Y8plS2qroIH1+i7+i6hXgviJa52KrjNW6BPVnZBXi6edmG4gCgqyvKY7eHYTTTe475o0KoxyMuUCx9/BjR25DFPniUqw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SPvy9FotbadlXLrl33D90SpicFg4v916kmx07Th8N8k=; b=SuXI337wX6Cv8eYBW8scLYKogqPUE+nDLM8BxpY5Ku/fYz6wZKFAYaXLY5nGqAjRJzUOO5S0FJStvVy72qBiBfXc7bUrVuvONDA8fZ1S1AZ7bI6S4lFnLzeOVga2fPB+X50G1X3Z+bC6DsiFcNEmM8DCa7ljyRqkn1q5vC0J5dzSMxe0wqPB/QQZziXwajjl0wYcuWI4fJxKvJswJ+sBBxZ8TgtyNOCXJcuRZPvblKjyOFiygjpJiAPUOAPs+BPeMVVoTMTprLc58n7ra1dE7kghDUuoGXyJ05WUz+T4v3ec9xTgEfhgImKExdLrX3bhzIF2LS3KLghuRvAqSYHoEw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ncsc.gov.uk;dmarc=pass action=none header.from=ncsc.gov.uk;dkim=pass header.d=ncsc.gov.uk;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SPvy9FotbadlXLrl33D90SpicFg4v916kmx07Th8N8k=; b=C9bT8oE9tyC6uGmjMlRct/FPclGOkg+2OV1cG/5s+i9DI30t9ajY6KmdqzxVocu/r2qFHj0y73t3SVeqHqc4KVbSFDLzWpqOoiqkuiBHjwvFqdquy8SWQ4qUuFBUfiDJc6EnJtQwYHTQpu48pidkSyHApednOoJRdKpmhxmyuFo=
Received: from LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM (20.176.157.151) by LO2P123MB2239.GBRP123.PROD.OUTLOOK.COM (20.176.155.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.14; Sat, 20 Jul 2019 09:04:57 +0000
Received: from LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM ([fe80::815e:ea4e:7133:7de0]) by LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM ([fe80::815e:ea4e:7133:7de0%5]) with mapi id 15.20.2094.013; Sat, 20 Jul 2019 09:04:57 +0000
From: Ian Levy <ian.levy@ncsc.gov.uk>
To: Scott Kitterman <sklist@kitterman.com>, "dmarc@ietf.org" <dmarc@ietf.org>
Thread-Topic: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
Thread-Index: AQHVONo/47N98C6WmEulUndQgJsxhKbHRCGAgAAJaoCAAaTUgIAFVuCAgAD9pACAADq9AIAAL2GAgADcIgCAAOphAIAACBSggABi5ACAAP51AIAAYX5g
Date: Sat, 20 Jul 2019 09:04:57 +0000
Message-ID: <LO2P123MB2285EDA7977A5005136FBF21C9CA0@LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM>
References: <CAL0qLwbbz_UhBLsURg=eXhRBC2g9OghiN==T9Uq9pFuLtd=b7w@mail.gmail.com> <LO2P123MB2285D18172BC95D42A968B1CC9CB0@LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM> <CAJ4XoYc2tMoLebD-qiau7-aB3Lo0m0k3JB6tg0b-FN7yTif4jw@mail.gmail.com> <2333259.aoXCTIVaPC@l5580>
In-Reply-To: <2333259.aoXCTIVaPC@l5580>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ian.levy@ncsc.gov.uk;
x-originating-ip: [51.141.34.27]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 841ce6fa-a7d6-4fa3-ed1b-08d70cf156af
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LO2P123MB2239;
x-ms-traffictypediagnostic: LO2P123MB2239:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <LO2P123MB223901C038AE2F9D384CE714C9CA0@LO2P123MB2239.GBRP123.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:1201;
x-forefront-prvs: 0104247462
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(346002)(396003)(136003)(39850400004)(366004)(189003)(199004)(13464003)(66946007)(76116006)(8676002)(66446008)(68736007)(14454004)(52536014)(33656002)(66476007)(478600001)(66556008)(64756008)(86362001)(25786009)(74316002)(66066001)(966005)(7736002)(305945005)(45080400002)(2906002)(229853002)(256004)(14444005)(44832011)(486006)(81156014)(8936002)(81166006)(55016002)(6306002)(9686003)(6436002)(5660300002)(6246003)(99286004)(316002)(110136005)(53936002)(102836004)(476003)(6506007)(55236004)(53546011)(71190400001)(71200400001)(2501003)(7696005)(76176011)(3846002)(6116002)(26005)(11346002)(446003)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:LO2P123MB2239; H:LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ncsc.gov.uk does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: GQztNrE+RhzfMFJHSmc2f+/t8S7TWgqCe0wE0I+H6azzvElufDfPWazWycpSl+o0UfZlFhnymPh4/jNzTaC2kZJVddx/4dXrHXnYt1uSLhFuuCZR618g9iIXd/fdgn5Hg3hwQK0/6NO7PKDa9WvwTw3t4UoJ16oDJBqS0ELMSnMsrzwZGSAfB//7W1N45TZCCJx+4k9mGibz35o2ziu1dgiFusnMJEU9FvSDGcs5NNh0Pm+Q39rP+XAjV83zkBU4DTOXWJqdSd6c4euxQTU3EgbBuuvGpdT7K4hYhezqUVYbTFErAf+cQJpN42tjDcDjZtnxGrm4lu4OkMqcNreVCD/+2rqp6Mg8qnPO+/75tfKBh0Yy+DHxgJayiPcLZkkAS5ZSmu47fpm69stCz5qE0ml3EKlSJIIS1IFlJOJcbg4=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ncsc.gov.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: 841ce6fa-a7d6-4fa3-ed1b-08d70cf156af
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2019 09:04:57.6016 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ian40919@ncsc.gov.uk
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB2239
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/Yl5wKuWQcL-i3RfFz2Xmw0AW20I>
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 09:05:03 -0000

>> 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.

+1.

Ta.

I.


--
Dr Ian Levy
Technical Director
National Cyber Security Centre
ian@ncsc.gov.uk

Staff Officer : Kate Atkins, kate.a@ncsc.gov.uk

(I work stupid hours and weird times – that doesn’t mean you have to. If this arrives outside your normal working hours, don’t feel compelled to respond immediately!)

-----Original Message-----
From: dmarc <dmarc-bounces@ietf.org>; On Behalf Of Scott Kitterman
Sent: 20 July 2019 04:15
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

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



_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmarc&amp;data=02%7C01%7Cian.levy%40ncsc.gov.uk%7C7c7b41070b5a449edbc008d70cc0908f%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C636991893511878654&amp;sdata=Ng9fs%2FJa8R9Orm%2BPqtiq7IdLUXz0K%2FyyFLQRtGw%2FlJ4%3D&amp;reserved=0
This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright ©