On Tuesday, June 4, 2019 6:37:47 PM EDT Tim Draegen wrote: > > On May 27, 2019, at 6:59 PM, Scott Kitterman <[email protected]> wrote: > > > > On Monday, May 27, 2019 6:53:17 PM EDT [email protected] wrote: > >> 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 (Domain-based Message Authentication, > >> > >> Reporting, and Conformance) Extension For PSDs (Public Suffix Domains) > >> Author : Scott Kitterman > >> > >> Filename : draft-ietf-dmarc-psd-04.txt > >> Pages : 11 > >> Date : 2019-05-27 > > > > There isn't much to this update. It corrects one typo and reverts the RUF > > MUST NOT as discussed on the list. As far as I'm aware there are no other > > pending issues in the WG with the draft. > > Hi Scott, I've reviewed the doc and have made some comments. Feel free to > dispose of them as you will. > > I had a hard time with the introduction. "sets of domains within a single > organization" and "lower level policy" left me not knowing what I was > reading. I'm unhappy just complaining, so I took a stab at this admittedly > difficult section. The original: > > DMARC [RFC7489] provides a mechanism for publishing organizational > policy information to email receivers. DMARC [RFC7489] allows policy > to be specified for both individual domains and sets of domains > within a single organization. For domains above the organizational > level in the DNS tree, policy can only be published for the exact > domain. There is no method available to such domains to express > lower level policy or receive feedback reporting for sets of domains. > This prevents policy application to non-existent domains and > identification of domain abuse in email, which can be important for > brand and consumer protection. > > My stab: > > DMARC [RFC7489] provides a mechanism for publishing organizational > policy information to email receivers. DMARC [RFC7489] allows policy > to be specified for both individual domains and for organizational > domains and their sub-domains > within a single organization. For 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 such 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.
Incorporated. > > The example section doesn't read like the rest of the draft and was hard for > me to read through. Original: > > This would provide policy and feedback for mail sent from > @gov.example, but not @tax.gov.example and there is no way to publish > an organizational level policy that would do so. While, in theory, > receivers could reject mail from non-existent domains, not all > receivers do so. Non-existence of the sending domain can be a factor > in a mail delivery decision, but is not generally treated as > definitive on its own. > > Again my stab: > > 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 @tax.gov.example does not and cannot > fall under a DMARC policy. Incorporated. > > I don't have too much more, I just got just caught up in the initial read. > This paragraph contains a construct that was confusing to me: > > This memo provides a simple extension to DMARC [RFC7489] to allow > operators of Public Suffix Domains (PSDs) to express policy for > groups of subdomains, extends the DMARC [RFC7489] policy query > functionality to detect and process such a policy, describes receiver > feedback for such policies, and provides controls to mitigate > potential privacy considerations associated with this extension. > > ^^^ why "groups of subdomains" and not just "subdomains"? One step further, > why not "express policy at the level of the PSD that covers all > organizational domains that do not explicitly publish DMARC records"? Incorporated. > > OK, two more things: > > 2.3. Longest PSD > > Organizational Domain (DMARC [RFC7489] Section 3.2) with one label > removed. > > ^^^ "one left-most label removed"? Incorporated. > > Last thing: Security considerations might call out DNS cache poisoning as a > way to get reports for a PSD. Applies to vanilla DMARC too, but the scope > and potential breadth of information with PSD-DMARC is really interesting. > I imagine an attack that gets .COM listed into the PSD Registry for a > specific report generator.. combined with cache poisoning and the poor > report generator would probably explode at best. I added this to security considerations (and the new informational reference): The risks of the issues identified in [RFC7489], Section 12.3, DNS Security, are amplified by PSD DMARC. In particular, DNS cache poisoning (or Name Chaining), see [RFC3833] for details, consequences are increased because a sucessful attack would potentially have a much wider scope. Thanks, Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
