Re: [dmarc-ietf] draft-ietf-dmarc-psd review

["Stan Kalisch" <[e-mail]>]

Scott, I have two editorial nits that account for a grand total of three characters. It seemed less complicated to just send a PR in Github, so I did.


Stan

On Sat, Jul 27, 2019, at 4:45 PM, Scott Kitterman wrote:
> On Monday, July 22, 2019 12:23:15 PM EDT Murray S. Kucherawy wrote:
> > Reviewing as the document shepherd:
> > 
> > Abstract
> > 
> > [...]
> > organization can use to improve mail handling. DMARC policies can be
> > applied at the individual domain level or for a set of domains at the
> > organizational level.
> > 
> > I think the abstract is a bit too abstract. Which set of domains?
> > 
> > 
> > The design of DMARC precludes grouping
> > policies for a set of domains above the organizational level, such as
> > TLDs (Top Level Domains).
> > 
> > Is that the same set?
> 
> I updated the paragraph to start:
> 
>  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 policies can be
>  applied to individual domains or to all domains within an
>  organization. The design of DMARC precludes grouping policies for
>  domains based on policy published above the organizational level,
>  such as TLDs (Top Level Domains). 
> 
> Does that clear those comments up?
> 
> 
> > These types of domains (which are not all
> > at the top level of the DNS tree) can be collectively referred to as
> > Public Suffix Domains (PSDs).
> > 
> > What "types" are there?
> 
> Changed to:
> 
>  organization. The design of DMARC precludes grouping policies for
>  domains based on policy published above the organizational level,
>  such as TLDs (Top Level Domains). Domains at this higher level of
>  the DNS tree (but not necessarily at the top of the DNS tree) can be
>  collectively referred to as Public Suffix Domains (PSDs). 
> 
> > For the subset of PSDs that require
> > DMARC usage, this memo describes an extension to DMARC to enable
> > DMARC functionality for such domains.
> >
> > What's the requirement? 
> 
> Given that the document no longer contains such a constraint, I've updated my 
> working copy to say:
> 
> This memo describes an extension to DMARC to enable DMARC functionality PSDs.
> 
> > 1. Introduction
> > 
> > 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
> > 
> > Which sets?
> > 
> Comment is OBE based on previous changes.
> 
> > 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.
> > 
> > Still too abstract. I don't know what sort of set groupings you might
> > be after here.
> 
> I think the new text is better. Please check and let me know if it's there 
> yet or not.
> 
> > This prevents policy application to non-existent domains and
> > identification of domain abuse in email, which can be important for
> > brand and consumer protection.
> > 
> > As an example, imagine a country code TLD (ccTLD) which has public
> > subdomains for government and commercial use (.gov.example and
> > .com.example). Within the .gov.example public suffix, use of DMARC
> > [RFC7489] has been mandated and .gov.example has published its own
> > DMARC [RFC7489] record:
> > 
> > "v=DMARC1;p=reject;rua=mailto:[e-mail]"
> > 
> > Can we add spaces after the semicolons? I know this is legal format
> > but it would be more readable.
> 
> Changed.
> 
> > This memo provides a simple extension to DMARC [RFC7489] to allow
> > 
> > s/memo/document/g
> 
> Changed throughout.
> 
> > operators of Public Suffix Domains (PSDs) to express policy for
> > groups of subdomains, extends the DMARC [RFC7489] policy query
> > 
> > "groups of subdomains" suggests the capability of creating a policy
> > that applies to parts of the subtree only, or different policies for
> > different parts of the subtree. If that's not what we're actually
> > defining here, this should be reworded.
> 
> OBE to previous comments.
> 
> > As an additional benefit, the PSD DMARC extension will clarify
> > 
> > s/will clarify/clarifies/
> 
> Changed.
> 
> > existing requirements. Based on the requirements of DMARC [RFC7489],
> > DMARC should function above the organizational level for exact domain
> > matches (i.e. if a DMARC record were published for 'example', then
> > mail from example@example should be subject to DMARC processing).
> > Testing had revealed that this is not consistently applied in
> > different implementations. PSD DMARC will help clarify that DMARC is
> > 
> > s/will help clarify/clarifies/
> 
> Changed.
> 
> > ....and saying it twice in the same paragraph is probably not necessary.
> 
> And then deleted the sentence.
> > 
> > not limited to organizational domains and their sub-domains.
> > 
> > There are two types of Public Suffix Operators (PSOs) for which this
> > extension would be useful and appropriate:
> > 
> > o Branded PSDs (e.g., ".google"): These domains are effectively
> > Organizational Domains as discussed in DMARC [RFC7489]. They
> > control all subdomains of the tree. These are effectively private
> > domains, but listed in the Public Suffix List. They are treated
> > as Public for DMARC [RFC7489] purposes. They require the same
> > protections as DMARC [RFC7489] Organizational Domains, but are
> > currently excluded.
> > 
> > How are they current excluded? Is this because they're on the PSL, so
> > DMARC treats them differently?
> 
> Yes. Per the DMARC definition, they are not organizational domains.
> 
> > o Multi-organization PSDs that require DMARC usage (e.g., ".bank"):
> > Because existing Organizational Domains using this PSD have their
> > own DMARC policy, the applicability of this extension is for non-
> > existent domains. The extension allows the brand protection
> > benefits of DMARC [RFC7489] to extend to the entire PSD, including
> > cousin domains of registered organizations.
> > 
> > An example would be useful here.
> 
> I've added this:
> 
>  As an example, take the ".gov.example" described above and add that
>  for this entity emails about tax returns are sent from
>  tax.gov.example. It would not be surprising if fraudulent emails
>  were sent purporting to be from taxes.gov.example (taxes is a cousin
>  of tax - different enough to evade DMARC protection, but similar
>  enough to potentially confuse users). As defined in DMARC [RFC7489],
>  a DMARC record could be published for tax.gov.example, but there is
>  no general solution to publishing a DMARC policy to defend against
>  abuse of non-existent cousins such as taxes.gov.example. While an
>  explicit record could be published for this one domain, the universe
>  of possible cousins is such that this approach does not scale.
> 
> How's that?
> 
> > Due to the design of DMARC [RFC7489] and the nature of the Internet
> > email architecture [RFC5598], there are interoperability issues
> > associated with DMARC [RFC7489] deployment. These are discussed in
> > Interoperability Issues between DMARC and Indirect Email Flows
> > [RFC7960]. These issues are not applicable to PSDs, since they
> > (e.g., the ".gov.example" used above) do not send mail.
> > 
> > DMARC doesn't need to be followed by its RFC number every time.
> 
> I went through and removed most of these. I tried to remove them so that it's 
> mostly there when talking about DMARC the RFC, not DMARC the protocol.
> 
> > 2.2. Public Suffix Domain (PSD)
> > 
> > The global Internet Domain Name System (DNS) is documented in
> > numerous Requests for Comment (RFC). It defines a tree of names
> > starting with root, ".", immediately below which are Top Level Domain
> > names such as ".com" and ".us". They are not available for private
> > registration. In many cases the public portion of the DNS tree is
> > more than one level deep. PSD DMARC includes all public domains
> > above the organizational level in the tree, e.g., ".gov.uk".
> > 
> > I don't know what that last sentence means. PSD DMARC is an
> > extension; how does it include domains?
> 
> Deleted the sentence. I don't think it is necessary for the definition, so 
> let's not confuse things.
> 
> > 2.4. Public Suffix Operator (PSO)
> > 
> > A Public Suffix Operator manages operations within their PSD.
> > 
> > s/their/its/; "operator" is singular.
> 
> Changed.
> 
> > 2.6. Non-existent Domains
> > 
> > For DMARC [RFC7489] purposes, a non-existent domain is a domain name
> > that publishes none of A, AAAA, or MX records that the receiver is
> > willing to accept. This is a broader definition than that in
> > NXDOMAIN [RFC8020].
> > 
> > Is there any discussion that could be referenced about DNS RRs that
> > one is not willing to accept?
> 
> OBE. Removed that from the definition based on the WGLC discussion about the 
> definition.
> 
> > 3.2. Section 6.1 DMARC Policy Record
> > 
> > PSD DMARC records are published as a subdomain of the PSD. For the
> > PSD ".example", the PSO would post DMARC policy in a TXT record at
> > "_dmarc.example".
> > 
> > Don't you mean the PSD DMARC record is a record in the zone of the
> > PSD? It's not a subdomain.
> 
> Here's what's in RFC 7489 about DMARC record publishing:
> 
> 6.1. DMARC Policy Record
> 
>  Domain Owner DMARC preferences are stored as DNS TXT records in
>  subdomains named "_dmarc". For example, the Domain Owner of
>  "example.com" would post DMARC preferences in a TXT record at
>  "_dmarc.example.com".
> 
> I think our 3.2 is equivalent and adequate given this section is a modification 
> to RFC 7489 Section 6.1. I did not make a change.
> 
> > 3.3. Section 6.5. Domain Owner Actions
> > 
> > In addition to the DMARC [RFC7489] domain owner actions, PSOs that
> > require use of DMARC ought to make that information available to
> > receivers.
> > By what mechanism?
> 
> Changed to:
> 
>  In addition to the DMARC domain owner actions, PSOs that require use
>  of DMARC and participate in PSD DMARC ought to make that information
>  available to receivers. The mechanism for doing so is one of the
>  experimental elements of this document. See the experiment
>  description (Appendix A).
> 
> > 3.4. Section 6.6.3. Policy Discovery
> > 
> > A new step between step 3 and 4 is added:
> > 
> > 3A. If the set is now empty and the longest PSD (Section 2.3) of the
> > Organizational Domain is one that the receiver has determined is
> > acceptable for PSD DMARC, the Mail Receiver MUST query the DNS for
> > a DMARC TXT record at the DNS domain matching the longest PSD
> > (Section 2.3) in place of the RFC5322.From domain in the message
> > (if different). A possibly empty set of records is returned.
> > 
> > Section 6.6.3 of DMARC doesn't talk about "acceptable for DMARC", so I
> > don't know what "acceptable for PSD DMARC" might mean.
> 
> Changed to:
> 
>  3A. If the set is now empty and the longest PSD (Section 2.3) of the
>  Organizational Domain is one that the receiver has determined is
>  acceptable for PSD DMARC (discussed in the experiment description
>  (Appendix A)), the Mail Receiver MUST query the DNS for a DMARC
>  TXT record at the DNS domain matching the longest PSD
>  (Section 2.3) in place of the RFC5322.From domain in the message
>  (if different). A possibly empty set of records is returned.
> 
> > Section numbers in the prose of this section should make clear which
> > document they're referencing.
> 
> I checked and any reference to an RFC7489 paragraph number that's in the text 
> is labeled as such.
> > 
> > 3.5. Section 7. DMARC Feedback
> > 
> > Operational note for PSD DMARC: For PSOs, feedback for non-existent
> > domains is desired and useful. See Section 4 for discussion of
> > Privacy Considerations.
> > 
> > Section 4 of which document?
> 
> Added 'of this document'.
> 
> > 4. Privacy Considerations
> > 
> > These privacy considerations are developed based on the requiremetns
> > 
> > typo
> > 
> > of [RFC6973]. The Privacy Considerations of [RFC7489] apply to this
> > document.
> > 
> > 4.1. Feedback leakage
> > 
> > Providing feedback reporting to PSOs can, in some cases, create
> > leakage of information outside of an organization to the PSO. This
> > leakage could be potentially be utilized as part of a program of
> > 
> > Remove one of the "be"s.
> 
> Fixed.
> 
> > pervasive surveillance (See [RFC7624]). There are roughly three
> > cases to consider:
> > 
> > o Single Organization PSDs (e.g., ".google"), RUA and RUF reports
> > based on PSD DMARC have the potential to contain information about
> > emails related to entities managed by the organization. Since
> > both the PSO and the Organizational Domain owners are common,
> > there is no additional privacy risk for either normal or non-
> > existent Domain reporting due to PSD DMARC.
> > 
> > o Multi-organization PSDs that require DMARC usage (e.g., ".bank"):
> > PSD DMARC based reports will only be generated for domains that do
> > not publish a DMARC policy at the organizational or host level.
> > For domains that do publish the required DMARC policy records, the
> > feedback reporting addresses (RUA and RUF) of the organization (or
> > hosts) will be used. The only direct feedback leakage risk for
> > these PSDs are for Organizational Domains that are out of
> > compliance with PSD policy. Data on non-existent cousin domains
> > would be sent to the PSO.
> > 
> > This is the second use of "cousin domain". An example here or at the
> > first use might be a good idea.
> 
> Added at first use.
> 
> And that's the last comment.
> 
> I intend to post a revision shortly so the group can more easily review my 
> proposed changes based on WGLC.
> 
> Scott K
> 
> 
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>