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

[Scott Kitterman <[e-mail]>]

Is silence concurrence?  Comments inline.  Please let me know how to proceed 
on updating the draft.   I'd appreciate anyone else's feedback too.

Scott K

On Wednesday, July 31, 2019 8:28:17 PM EDT Murray S. Kucherawy wrote:
> Thanks for this, much better.  Some additional feedback.
> 
> Please note (everyone) that I'm offering these as clarifying contributions
> to text; I'm not prescribing or proscribing anything.  If the text I'm
> proposing isn't worthy of consensus, please speak up.
> 
> On Sat, Jul 27, 2019 at 1:45 PM Scott Kitterman <[e-mail]>
> 
> wrote:
> > 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?
> 
> That last sentence still puzzles me, and I think it's the term "grouping"
> that gives me trouble.
> 
> 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.  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 the Public Suffix List (PSL) to be ineligible for DMARC enforcement.
> 
> 
> If we like this, I suggest it or language like it can also be used to
> rework the first paragraph of the Introduction section in -05.  To
> import DMARC definitions into the introduction, you could say that
> DMARC presumes that a domain is either on the PSL or is an OD, and
> never both,.

I think this is generally fine, but it should be public suffix list (not 
capitalized) as that's what's used in the main body of RFC 7489.  Appendix A.
6.1 uses the PSL as an example, but it's only one possible source of such 
data.

What would you (you = anyone) suggest for the introduction rewrite?

> > >    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.
> 
> Thanks.  Now for the text right before the example; I suggest:
> 
> As an example, ...  Suppose there exists a registered domain
> "tax.gov.example" that is responsible for taxation in this imagined
> country.  However, by exploiting the typically unauthenticated nature of
> email, there are regular malicious campaigns to impersonate this
> organization that use similar-looking ("cousin") domains such as
> "t4x.gov.example".  These domains are not registered.  Within the
> ".gov.example" public suffix, use of DMARC has been mandated, so
> "gov.example" publishes the following DMARC record:
> 
> ...
> 
> Defensively registering all variants of "tax" is obviously not a scalable
> strategy.  The intent of this specification, therefore, is to enhance the
> DMARC algorithm by enabling an agent receiving such a message to be able to
> determine that a relevant policy is present at "gov.example", which is
> precluded by the current DMARC algorithm.

Looks good to me.  Unless someone else suggests differently (soon), I'll do 
that.

> > >    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.
> 
> I suggest "unable to benefit from DMARC" rather than "excluded".
> "Excluded" makes me think DMARC specifically targeted them as not worthy of
> or appropriate for inclusion, which isn't the case.

OK.

> > >    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?
> 
> Great, and it's also pretty much what I proposed above.  (Apologies; my
> read-ahead failed.)  I suggest picking one or the other, but I think it's
> of benefit to put this higher up where my suggestion is to set context.

OK.  I'm fine with either.

> >    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.
> 
> Yeah I think you got most of them but there are a few I would still
> reduce.  Not a big deal unless others concur; the RFC Editor will probably
> chime in as well.

OK.  No further changes planned then.

> > 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.
> 
> The text present now for 2.2 defines the name/label structure of the DNS,
> but doesn't actually say what a PSD is.
> 
> This is an interesting problem, because we are attempting to describe (or
> ascribe) semantics of the DNS that simply do not exist.  The DNS is a
> hierarchical naming structure and related database, plain and simple; we
> are attempting to ascribe to it boundaries that are not there in DNS-land.
> But we happen to do lookups in it using DNS APIs.
> 
> So let's try removing the DNS from the definition:
> 
> The domain name structure consists of a tree of names, each of which is
> made of a sequence of words ("labels") separated by period characters.  The
> root of the tree is simply called ".".  The Internet community at large,
> through processes and policies external to this work, selects points in
> this tree at which to register domain names "owned" by independent
> organizations.  Real-world examples are ".com", ".org", ".us", and
> ".gov.uk". Names at which such registrations occur are called Public Suffix
> Domains (PSDs), and a registration consists of a label selected by the
> registrant to which a desirable PSD is appended.  For example, "ietf.org"
> is a registered domain name, and ".org" is its PSD.
> 
> While I'm here, I suggest 2.3 is a little terse.  Maybe:
> 
> The longest PSD is the PSD matching more labels in the domain name under
> evaluation than any other PSL entry.

I'm fine with both.

> > 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.
> 
> Embarrassing.  RFC7489 6.1's text you cited is unfortunate.  I would change
> "in subdomains named" to "at labels named".
> 
> But also, why do we need this section?  The PSD DMARC record is in the same
> place as one would expect it having read only RFC7489, correct?

On reflection, I think it can be deleted.  Anyone else?
> 
> > 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.
> 
> I'm talking about the "Section 2.3" here, and the "Section x.y" strings in
> the section headings in Section 3.  Since you are pointing back to RFC7489
> frequently, I thought it might be best to say "Section 2.3 of this
> document", or "Section x.y of RFC7489", as appropriate.

Since (as an example) 'longest PSD (Section 2.3)' comes from the XML <xref 
target="lpsd">longest PSD</xref>, I'm not sure how to manage that in xml2rfc 
language.  If anyone knows how, please let me know and I'll be glad to do it.

> Also in the example in the paragraph below here in the document, you're
> using ".cctld"; should that be ".example" or ".cctld.example"?

OK.

> One final thing: I added a sentence at the end of my proposed Abstract that
> tries to highlight that domains on the PSL also need to be checked and not
> special-cased when one receives mail from a PSL.  In order to tie it to the
> experiment, I suggest this (as a new section at the end; reorder at your
> discretion):
> 
> 3.7.  PSDs Are Eligible For DMARC
> 
> Experience with DMARC has shown that some implementations short-circuit
> messages, bypassing DMARC policy application, when the domain name
> extracted by the receiver (from the RFC5322.From) is on the PSL.  This
> prevents the capability being created by this specification.  Therefore,
> the following paragraph is appended to Section 6.6.1 of RFC7489:
> 
> Note that domain names that appear on the Public Suffix List are not exempt
> from DMARC policy application and reporting.

OK.