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

Ian Levy <ian.levy@ncsc.gov.uk> Fri, 19 July 2019 07:29 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 49FB912012E for <dmarc@ietfa.amsl.com>; Fri, 19 Jul 2019 00:29:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 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] 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 97uw0lanh3KS for <dmarc@ietfa.amsl.com>; Fri, 19 Jul 2019 00:29:06 -0700 (PDT)
Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110138.outbound.protection.outlook.com [40.107.11.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5761120125 for <dmarc@ietf.org>; Fri, 19 Jul 2019 00:29:05 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hwkmOA02CdEeDKmwgnHks3hTPTBOOZ9Z6zT6wejmjF4cGLRZuAa7KxbAGkPw0Tyt8jeGWYtMBeEwjCWB/Z1HPYHeFlRih6r7oR7y4+Bztq9fWVuz2eMIloDPM4N0f5eXAJAjwcZfrJUtay5AnDcljSe6Mn/byBa6h/DKd0SVppX3k3tfhoFxJmEimMvLFv35tjmHigZeQ1sGNsbU3u4XZpJKJY49WApqrY2SOJjdG1BCh5rFzXKEPtM1Ej1fHeyASsPmG7BeFcQ2D27pflvnTSxQjgpa97bxRK8Y4G4dWEVcW/2mhmdwZLuwAh9mZHHLAfVCirBI1iJxDkwTuHgDfQ==
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=IUyEv6VDQ2mL00b6+WewH7ha5KXZClHJX+KLFERAVHg=; b=TSI4gKYc9aIV6ABdktGC4eSY2PGLSIsfmV+M54ewY9/wd52ZrN/6eluBsoIixYnynRC3xeCj1xeU+Eo118DMviEPmn7ey5PBshrdtw7h/yW035wlZykI/30AtCjAd3xs4YtlZ4ePSrha9QtTeejOchuUyorGPhYL6UV1fJxJwaHaXKMvLrEoRqguyXsrlAuNCu0qKUXCJ/f7YvupY0UErjZ7BQ+I7hZhjIwyWzRYppcK5mxSPmmJTft00TkMgsOzlG2p1OcrTaBxC4z4Sy14ENGcwx6GFoRGsaTPOmY/wWtYtmmV0039LF3ZQSz9jdLsUx0k3p4roixzTAKUZuZDFQ==
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=IUyEv6VDQ2mL00b6+WewH7ha5KXZClHJX+KLFERAVHg=; b=gDHu6E+TQaMKYly1VrGQE+IW3qBSBxIXXg4J2YyFKUnYTZl7S6BtE43/JQDbUm6KV8W5E2xmq07aS0AGJLzRWtNfTruua9ZTvjb4CVx5BYFJiZWt39OlMfmqfs+/oKP+TZMl+xLrt3L7gVENMzyLFmUdqNFrff3E4W6RWzZ672g=
Received: from LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM (20.176.157.151) by LO2P123MB2544.GBRP123.PROD.OUTLOOK.COM (20.176.157.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Fri, 19 Jul 2019 07:29:03 +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.2073.012; Fri, 19 Jul 2019 07:29:03 +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/47N98C6WmEulUndQgJsxhKbHRCGAgAAJaoCAAaTUgIAFVuCAgAD9pACAADq9AIAAL2GAgADcIgCAAOphAIAACBSg
Date: Fri, 19 Jul 2019 07:29:03 +0000
Message-ID: <LO2P123MB2285D18172BC95D42A968B1CC9CB0@LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM>
References: <CAL0qLwbbz_UhBLsURg=eXhRBC2g9OghiN==T9Uq9pFuLtd=b7w@mail.gmail.com> <4249121.lBB2AW0kmB@l5580> <CABuGu1qGJq2fes9B1vwb1v=JMi3HcydvzDvoi0+ZrEwC4rYk1A@mail.gmail.com> <3280991.vD5HP6B0ME@l5580>
In-Reply-To: <3280991.vD5HP6B0ME@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.140.114.144]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: aa36305d-2066-40f4-6b6a-08d70c1ac67e
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:LO2P123MB2544;
x-ms-traffictypediagnostic: LO2P123MB2544:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <LO2P123MB254426A5E3FBF62FC59879BDC9CB0@LO2P123MB2544.GBRP123.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:1201;
x-forefront-prvs: 01039C93E4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(376002)(39850400004)(136003)(396003)(366004)(189003)(199004)(51444003)(13464003)(66066001)(14444005)(86362001)(53546011)(76176011)(44832011)(102836004)(186003)(7696005)(71200400001)(26005)(6506007)(6436002)(53936002)(316002)(476003)(6246003)(486006)(99286004)(9686003)(71190400001)(6306002)(446003)(11346002)(55016002)(66446008)(25786009)(55236004)(64756008)(81156014)(7736002)(478600001)(5660300002)(2906002)(561944003)(966005)(45080400002)(66476007)(81166006)(6116002)(14454004)(256004)(229853002)(8936002)(76116006)(8676002)(33656002)(68736007)(66556008)(3846002)(110136005)(74316002)(52536014)(305945005)(2501003)(66946007); DIR:OUT; SFP:1102; SCL:1; SRVR:LO2P123MB2544; 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: qMEuubfZQcU0mJ/+VDLs7fRIcvFH6jDRs8s39wr6ZQvVZx1Q2JzRAqt6s7SMD5ENc35SFs9vzeT1HzY3su9ii1eW4TeOSp72St3Xsx/iZ7Rq8PONQVzZqb9hMxOv66PSo0L7QUmnhK+H5Dk6h7TR7siVpWlGwAE7DYkAUAtBc9G+PiARTp1JPoT/Yb2ewb1P6TWFTlosi5oTAuejdZVAbYCAWuElYucjfVyFiBYrFb/CpKBDK+QrbQpYGqidiqntfJDcaLW8bw4a7/lKLKS7WmUDnghUWMlZtL2fL7CSzA0l9ekcbibC8H6LnGGtAFZpXfG384zg6T1S/D2ScjPTQ9JHBbSHrUNJnPpLNFrt2mo/l8F3s5jaEjHi4YqF4EdkC3+2jK4R2zpdpW1ZBv+tLwI+WjUnXBa9wY8GntpJaIU=
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: aa36305d-2066-40f4-6b6a-08d70c1ac67e
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2019 07:29:03.2802 (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: LO2P123MB2544
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/MrEj8WsoJce0yON-P6HrW4FQ4GM>
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 07:29:09 -0000

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

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: 19 July 2019 06:41
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

On Thursday, July 18, 2019 11:42:36 AM EDT Kurt Andersen (b) wrote:
> On Wed, Jul 17, 2019 at 7:35 PM Scott Kitterman <sklist@kitterman.com>;
>
> wrote:
> > > On July 17, 2019 8:14:54 PM UTC, "Kurt Andersen (b)" 
> > > <kboth@drkurt.com>;
> > >
> > > wrote:
> > > >Firstly, I'm a little concerned with the sentence which says 
> > > >'Note that "np" will be ignored for DMARC records published on 
> > > >subdomains of Organizational Domains and PSDs due to the effect 
> > > >of the DMARC policy discovery mechanism described in DMARC 
> > > >[RFC7489] Section 6.6.3.' I don't think that is an accurate 
> > > >portrayal. When DMARC evaluation libraries are updated to do both 
> > > >PSD lookups and handle the np tag, I would expect the presence of 
> > > >np tags below the PSD level would be processed exactly the way 
> > > >that any other tag in a DMARC record is processed. np will only 
> > > >be ignored (per the terms of the DMARC spec) when it is an 
> > > >"unrecognized" tag. I realized that this text is sort of picked 
> > > >up from the current description of "sp", but the inclusion of 
> > > >"and PSDs" makes it inaccurate. You can't publish an np record on 
> > > >a non-existent Org domain or any subdomain thereof
> >
> > At first, I thought Kurt was right, but after further thought, I 
> > don't think so.
> >
> > To review the 'sp' definition that I took this from:
> >
> > Imagine sub.sub.example.com where example.com is the org domain.  If 
> > sub.sub.example.com has no DMARC record, then the next lookup is for 
> > a DMARC record at the org domain (example.com).  If sub.example.com 
> > has a DMARC record with an 'sp' tag, it's never retrieved.
> >
> > The same thing would apply to 'np' when used in a non--PSD context.  
> > No different.
> >
> > Keeping in mind that our definition of non-existent is a domain that 
> > has none of A, AAAA, or MX.  It could have other types.  It could 
> > also have subdomains called "_dmarc" that have TXT records.  
> > Non-existent domains (in our
> > context)
> > can have DMARC records, so I think the description is correct, but 
> > narrowly focused.
>
> Most MTAs will also follow CNAMEs. Should they be included (along with 
> other things like DNAME records) within the scope of existence? I'm a 
> little concerned that we are making a special definition of "non-existence"
> which differs from the standard DNS concepts of NODATA and NXDOMAIN 
> without having a correspondingly special name.

OK.  I wish you'd jumped in earlier when we were discussing that exact topic.

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fdmarc%2F44sVJzvPkXkdT7Np-0ANr9Wm2Zc&amp;data=02%7C01%7Cian.levy%40ncsc.gov.uk%7Cfd04a584f3394adcaeba08d70c0bdebd%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C636991117441523973&amp;sdata=UZok5iWF4kKutpE%2F6%2FN43CwLPAgtGPbaRaLGh4Ge%2Bz0%3D&amp;reserved=0

If we want to take another run at this and put it in more standard DNS terminology, then maybe:

.... a domain for which there is an NXDOMAIN or NODATA response for A, AAAA, and MX records.

I think that cures John's concern with my last proposal and addresses yours as well (the response to a CNAME/DNAME is not NODATA/NXDOMAIN, so they are correctly followed).

> > Modifying the example I used above slightly:
> >
> > Imagine sub2.sub1.org.example where example has a PSD DMARC record 
> > with 'np', org.example has no DMARC record, sub1.org.example also 
> > has a DMARC record with 'np', and sub2.sub1.org.example has no DMARC 
> > record.  In this case, the policy lookup is for 
> > sub2.sub1.org.example (exact domain), org.example (org domain), and 
> > then example (PSD).  Just as with 'sp' and regular DMARC, 'np' (or
> > 'sp')
> > in non-org subdomains of PSDs don't get discovered.
>
> I was considering the case of a domain such as
> subX.sub1.org.pub2.pub1.example:
> * subX (and sub1) domains would only have direct lookup DMARC records 
> applied if they exist and would fall back to org
> * org would be direct unless it doesn't have a record in which case if 
> fall back to LPD (pub2's record)
> * pub2, pub1, and example would only have direct lookups since they 
> are already above the PSL line <-- this is where my concern with the "and PSDs"
> phrase resides

It's possible that could happen, but it's not the most general case.  There are probably a nearly infinite variety of ways this could work or not work, I don't think we have to describe them all.

> I'm not sure how well this maps to what we describe. I'm also 
> concerned that a wildcard null MX record at the org level would end up 
> having all subdomains "exist", but the policy that should be applied 
> would be the more restrictive "np" policy, not the (possibly) more permissive "sp" policy.

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.

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%7Cfd04a584f3394adcaeba08d70c0bdebd%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C636991117441523973&amp;sdata=zTGFs%2BLFVOPFLr%2Bx5w5%2BIbcSm9CQvCWPkAe77o7jaOc%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 ©