Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt
On Fri, Feb 19, 2021 at 3:02 PM Barry Leiba wrote: > I agree that the abstract is unclear. This makes no sense to me: > >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. > > I don't understand the distinction that it's trying to make between > the two possibilities. > I also don't see the antecedent to "these domains" in the final > sentence of that paragraph. > > Beyond that: > > 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. I think the use of "registered" seems to be the source of some of this confusion. 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; "facebook.com" was delegated to some company that now "owns" that piece of the namespace tree and can create whatever it wants under there without any external arrangement. To my mind, "register" involves a specific transaction, sometimes involving money, with whoever gates access to make those delegations. All that needs to be explained in the Introduction, not the Abstract. > But the Abstract has to explain enough for a reader to understand why > she might or might not be interested in getting the document and > reading it. So it's going to be tough to word it carefully and to > keep it concise. But we have to. > > Stressing a point: > We very clearly do NOT want to explain this stuff in the Abstract. In > fact, we don't have to explain much at all in the Abstract. What we > have to do is make sure that the Abstract doesn't say stuff that's > *wrong* or confusing. So let's try to find some fifth-grade language > that can suffice, and then make sure the Introduction has the right > words to make it clear to people who know how to do email, but who > don't already understand the issues involved here. > 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. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt
On 2/21/21 08:49, Chudow, Eric B CIV NSA DSAW (USA) wrote: > I think it's getting better, but I wouldn't call them Internet Naming > Authorities. Should we just call them higher-level entities? There are proper names for these actors - there's no need to be even more vague ... > Also, while the biggest help that PSD DMARC would make is for non-existent > organizational domains, it can also help with other domains that haven't > expressed a DMARC policy, so the abstract shouldn't only discuss unregistered > domains. Except for the few cases where the registrar for a given TLD mandates DMARC participation and/or certain policies, there should be no language that sounds like /imposing/ DMARC on domains where the domain owner/operator has not elected to do so. Loose language here will not be received well. --S. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt
I think it's getting better, but I wouldn't call them Internet Naming Authorities. Should we just call them higher-level entities? Also, while the biggest help that PSD DMARC would make is for non-existent organizational domains, it can also help with other domains that haven't expressed a DMARC policy, so the abstract shouldn't only discuss unregistered domains. How about this: -- DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a scalable mechanism by which a mail-originating organization can express policy preferences for validation and disposition of messages which purport to come from owned domains, as well as requesting feedback reporting about those message validation and disposition actions. These features allow the Domain Owner to detect and inhibit domain name abuse. DMARC is designed for use by individual Domain Owners or organizational Domain Owners for their domains and sub-domains. Consequently, DMARC preferences by higher-level entities that have Organizational Domains below them in the DNS hierarchy cannot be specified for sub-domains in their purview. Those higher-level entities have an interest in detecting and inhibiting domain name abuse for domain names within their section of the DNS tree, and message recipients have an interest in preventing deception by entities using those domain names as well. Since its deployment in 2015, use of DMARC has shown a clear need for the ability to express policy preferences for these domains. Domains at which higher-level entities accept registrations by multiple organizations or other separate entities are referred to as Public Suffix Domains (PSDs). This document describes an extension to DMARC to enable DMARC functionality for PSDs. It also addresses implementations that consider a domain on a Public Suffix List to be ineligible for DMARC enforcement. This document also describes an extension to DMARC to specify separate, often stricter, policy preferences for non-existent sub-domains. -- Thanks, -Eric ___ Eric Chudow DoD Cybersecurity Mitigations 410-854-5735, eric.b.chudow@mail.mil From: Douglas Foster Sent: Saturday, February 20, 2021 9:01 AM To: Dave Crocker Cc: Murray S. Kucherawy ; IETF DMARC WG Subject: Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt This wording attempts to address the objections by giving "registration" a specific context. I also rewrote some of it for readability. - - DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a scalable mechanism by which a mail-originating organization can policies and preferences for validation and disposition of messages which purport to come from owned domains, as well as requesting feedback reporting about those message validation and disposition actions. These features allow the domain owner to detect and inhibit domain name abuse. DMARC is designed for use by domain owners. Consequently it has no applicability for domains that have no owner because the domain has never been registered with an Internet Naming Authority. Those authorities have an interest in detecting and inhibiting abuse of the name registration process, and message recipients have an interest in preventing deception by entities using unregistered organization domain names. Domains at which Internet Naming Authorities perform registration 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. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-01.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : DMARC Aggregate Reporting Author : Alex Brotman Filename: draft-ietf-dmarc-aggregate-reporting-01.txt Pages : 20 Date: 2021-02-21 Abstract: DMARC allows for domain holders to request aggregate reports from receivers. This report is an XML document, and contains extensible elements that allow for other types of data to be specified later. The aggregate reports can be submitted to the domain holder's specified destination as supported by the receiver. This document (along with others) obsoletes RFC7489. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-aggregate-reporting-01 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-aggregate-reporting-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-aggregate-reporting-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Messages from the dmarc list for the week ending Sun Feb 21 06:02:35 2021
Count| Bytes | Who ++--- 3 (16.7%) | 69293 (31.0%) | Ken O'Driscoll 2 (11.1%) | 38298 (17.1%) | Douglas Foster 2 (11.1%) | 30251 (13.5%) | Brotman, Alex 2 (11.1%) | 11388 ( 5.1%) | Alessandro Vesely 2 (11.1%) | 7975 ( 3.6%) | John Levine 1 ( 5.6%) | 16802 ( 7.5%) | Dotzero 1 ( 5.6%) | 14282 ( 6.4%) | Dave Crocker 1 ( 5.6%) | 11935 ( 5.3%) | Murray S. Kucherawy 1 ( 5.6%) | 9068 ( 4.1%) | Kurt Andersen (b) 1 ( 5.6%) | 6093 ( 2.7%) | Barry Leiba 1 ( 5.6%) | 4888 ( 2.2%) | Dale R. Worley 1 ( 5.6%) | 3052 ( 1.4%) | ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
