Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt
Barry Leiba <barryleiba@computer.org> Thu, 25 February 2021 05:10 UTC
Return-Path: <barryleiba.mailing.lists@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 4EEF63A1254 for <dmarc@ietfa.amsl.com>; Wed, 24 Feb 2021 21:10:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.397
X-Spam-Level:
X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 AceUmggivbBb for <dmarc@ietfa.amsl.com>; Wed, 24 Feb 2021 21:10:26 -0800 (PST)
Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) (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 454343A1252 for <dmarc@ietf.org>; Wed, 24 Feb 2021 21:10:26 -0800 (PST)
Received: by mail-ej1-f52.google.com with SMTP id w1so6658240ejf.11 for <dmarc@ietf.org>; Wed, 24 Feb 2021 21:10:26 -0800 (PST)
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:content-transfer-encoding; bh=nJIL3NtY7/Cg0zIjYOJg0+AWRGq8s86IYpzY0NdmJTk=; b=HuVbnHBdzqL0bQhearqeHEbYbYnhJ6ym0K04eCi+GPZiNS4lM1dwuA30h0ltfEB47O 5oHpP2824i+jMtD7lz1cgrrDAyWga6ZP5veMdOiLpFs7CXKvXmkJ+AaNBq7o4Hd/MxJ3 jZ46zqodgFADpsJSlDL8z6w5K/hFcHMWLZUNuzCwFSq9czE7LfQIde73Gua4ykPmWZ3L C42HZE5emIIx5IA/Q6qAgnV/cSFKvma+Jm42+5/2rgCJUJAlQATmRexpj1DUxICTfjW3 R23kMICDN/4zyF+c7kJlW8XplKx0TtX9gnT4gicY/CLT0n/k9pExeMVjsZTSwyFEbJXb HBfg==
X-Gm-Message-State: AOAM5331WzoaaZH2XTcAM37jpBoH6bFVLeSwipRycbRtZjD33evpRLjj dy7NSwDvuz0S6uvB+Ux//by6VgN7QisnW8tsGhs=
X-Google-Smtp-Source: ABdhPJwMXzGMVwjNCPlm8W22FC9j0pqwxX29CfsFkI5ncFhjUEAGhGQDoNsqNpe1uorO0y6vd6nN1iJmLm7AjwRN1D4=
X-Received: by 2002:a17:907:2513:: with SMTP id y19mr963560ejl.241.1614229824576; Wed, 24 Feb 2021 21:10:24 -0800 (PST)
MIME-Version: 1.0
References: <161144436332.13490.10651420808048876097@ietfa.amsl.com> <CADyWQ+EhD0nz71dLtUFwb9V_6uuen-k6E5fpvrCg3ZYzfr2JSw@mail.gmail.com> <ba38a9e4-7f43-c747-2d90-f35de22a8399@gmail.com> <CAL0qLwZJaEBrXdE9JOZNOJAgR7iEzfMA86Csi2sNtE5JC7ROUQ@mail.gmail.com> <c5cd9239-b204-255a-48a3-1cdccf18464a@gmail.com> <CAL0qLwYrcg__sewPO+EWfJf-5uoHcnQpFqtw-QoXxngHTJvkAA@mail.gmail.com> <CAC4RtVDCeFQU9RTN6osPTrMpap-Djkx5+Czx=-nKqVeXnyEy1Q@mail.gmail.com> <CAL0qLwZXkRMLXS7mt28-vEKKk4HgWkP98P8kdYaS1XbcYQvSxQ@mail.gmail.com> <CALaySJLVGhaBhrmDSYayYrcU9JSq_pY6D8=KoirUGCrOeKeHCQ@mail.gmail.com>
In-Reply-To: <CALaySJLVGhaBhrmDSYayYrcU9JSq_pY6D8=KoirUGCrOeKeHCQ@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Thu, 25 Feb 2021 00:10:13 -0500
Message-ID: <CAC4RtVARxfJNUs+ve1ViDTF385QjLoyhw8JyKc-nALhuu=xoPA@mail.gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: Dave Crocker <dcrocker@gmail.com>, IETF DMARC WG <dmarc@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/Qzld0b9Dp25KAEGL8j_kHygPLAw>
Subject: Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt
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: Thu, 25 Feb 2021 05:10:28 -0000
OK, here's my proposal; please let me know what you think: — Abstract — OLD DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. The design of DMARC presumes that domain names represent either nodes in the tree below which registrations occur, or nodes where registrations have occurred; it does not permit a domain name to have both of these properties simultaneously. Since its deployment in 2015, use of DMARC has shown a clear need for the ability to express policy for these domains as well. Domains at which registrations can occur are referred to as Public Suffix Domains (PSDs). This document describes an extension to DMARC to enable DMARC functionality for PSDs. This document also seeks to address implementations that consider a domain on a public Suffix list to be ineligible for DMARC enforcement. NEW DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. DMARC uses a Public Suffix List (PSL) to determine what part of a domain name is the Public Suffix Domain (PSD), below which organizational domain names are created. DMARC allows organizational domains to specify policies that apply to their subdomains, but it does not give that flexibility to PSDs. This document describes an extension to DMARC to fully enable DMARC functionality for PSDs. This document also addresses implementations that consider a domain on a public Suffix list to be ineligible for DMARC enforcement. — Section 1 — OLD DMARC as specified presumes that domain names present in a PSL are not organizational domains and thus not subject to DMARC processing; domains are either organizational domains, sub-domains of organizational domains, or listed on a PSL. For domains listed in a PSL, i.e., TLDs and domains that exist between TLDs and organization level domains, policy can only be published for the exact domain. No method is available for these domains to express policy or receive feedback reporting for sub-domains. This missing method allows for the abuse of non-existent organizational-level domains and prevents identification of domain abuse in email. NEW DMARC as specified presumes that domain names present in a Public Suffix List (PSL) — Public Suffix Domains (PSDs) — are not organizational domains and are thus not subject to DMARC processing. In DMARC, domains fall into one of three categories: organizational domains, sub-domains of organizational domains, or PSDs. For PSDs, policy can only be published for the exact domain: no mechanism is available for PSDs to express policy or receive feedback reporting for sub-domains. The lack of such a mechanism allows for the abuse of non-existent organizational-level domains and hampers identification of domain abuse in email. — Section 1.1 — OLD As an example, imagine a country code TLD (ccTLD) which has public subdomains for government and commercial use (".gov.example" and ".com.example"). A PSL whose maintainer is aware of this country's domain structurewould include entries for both of these in the PSL, indicating that they are PSDs below which registrations can occur. Suppose further that there exists a domain "tax.gov.example", registered within ".gov.example", that is responsible for taxation in this imagined country. NEW As an example, imagine a Top-Level Domain (TLD), ".example", that has public subdomains for government and commercial use (".gov.example" and ".com.example"). A PSL whose maintainer is aware of this TLD’s domain structure would include entries for both of these in the PSL, indicating that they are PSDs below which organizational domains can be registered. Suppose further that there exists a legitimate domain called "tax.gov.example", registered within ".gov.example". OLD This DMARC record provides policy and a reporting destination for mail sent from @gov.example. However, due to DMARC's current method of discovering and applying policy at the organizational domain level, the non-existent organizational domain of @t4x.gov.example does not and cannot fall under a DMARC policy. NEW This DMARC record provides policy and a reporting destination for mail sent from @gov.example. Similarly, "tax.gov.example" will have a DMARC record that specifies policy for mail sent from addresses @tax.gov.example. However, due to DMARC's current method of discovering and applying policy at the organizational domain level, the non-existent organizational domain of @t4x.gov.example does not and cannot fall under a DMARC policy. -- Barry On Mon, Feb 22, 2021 at 9:33 AM Barry Leiba <barryleiba@computer.org> wrote: > > >> > I'm at a loss to understand what's confusing. I'm not convinced that "registrations" in the > >> > context of domain names is unclear to a reader familiar with this space. > >> > >> I am absolutely convinced that it is. Think of people in M3AAWG, for > >> whom this is very relevant. Many of them don't know much about > >> registries, registrars, and such, and in general, the average reader > >> won't understand the difference, from a "registration" standpoint, > >> between facebook.com (which is registered) and "www.facebook.com" > >> (which is not). To the average reader, "facebook.com" is registered > >> under com, and "www.facebook.com" is registered under facebook. And > >> the ones who don't think that will likely not understand why we can't > >> just talk about second-level domains and be done with it. > > > > Actually that's a community that I would expect to know exactly what all those terms mean and > > how they are all related. > > There clearly are some in that community who do. But there are many > there who don't. This stuff is more esoteric than those of us who are > in the middle of it often realize. > > > I think the use of "registered" seems to be the source of some of this confusion. > > Yes, exactly. > > > To work with the example you gave here, I agree that "facebook.com" is registered (under "com"), but > > disagree that "www.facebook.com" is registered at all; > > Right, of course it's not. I didn't say that it is: I said that > people who don't fully understand this stuff *think* it is, and that's > the part that the text isn't making clear. > > > To my mind, "register" involves a specific transaction, sometimes involving money, with whoever gates > > access to make those delegations. > > And that's what we need to explain better in the Introduction. > > > How's this?: > > > > DMARC (Domain-based Message Authentication, Reporting, and > > Conformance) is a scalable mechanism by which a mail-originating > > organization can express domain-level policies and preferences for > > message validation, disposition, and reporting, that a mail-receiving > > organization can use to improve mail handling. > > > > Within the Domain Name System (DNS) on the public Internet, which is > > organized as a tree, some nodes of that tree are reserved for use by > > registrars, who delegate sub-trees to other operators on request. DMARC currently > > permits expression of policy only for such sub-trees. There is a marked desire to > > be able to express policy for the reserved nodes as well. This document > > describes an experimental extension to DMARC to add that capability. > > > > If we like that as a replacement Abstract, I'll carry on and propose a revision to the Introduction. > > I don't think that really explains it properly either -- I think with > the above text, it's less confusing, but also not correct, or at least > not really indicative of what the document is proposing. > > I don't have time today, but give me a couple of days to work on the > Abstract and the Introduction/Example, and I'll propose some specific > text that we can try out. > > Barry > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc
- [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-10.… internet-drafts
- [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-ps… Tim Wicinski
- Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmar… Dave Crocker
- Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmar… Murray S. Kucherawy
- Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmar… Dave Crocker
- Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmar… Murray S. Kucherawy
- Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmar… Barry Leiba
- Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmar… Dave Crocker
- Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmar… Douglas Foster
- Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmar… Chudow, Eric B CIV NSA DSAW (USA)
- Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmar… Steven M Jones
- Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmar… Murray S. Kucherawy
- Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmar… Barry Leiba
- Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmar… Ken O'Driscoll
- Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmar… Dave Crocker
- Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmar… Douglas Foster
- Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmar… Dave Crocker
- Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmar… ned+dmarc
- Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmar… Douglas Foster
- Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmar… Ken O'Driscoll
- Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmar… Alessandro Vesely
- Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmar… Barry Leiba
- Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmar… Dave Crocker
- Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmar… Kurt Andersen (b)
- Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmar… Dave Crocker
- Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmar… Murray S. Kucherawy
- Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmar… Tim Wicinski
- Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmar… Barry Leiba
- Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmar… Tim Wicinski