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

Scott Kitterman <sklist@kitterman.com> Sat, 27 July 2019 20:45 UTC

Return-Path: <sklist@kitterman.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 7C6B5120096 for <dmarc@ietfa.amsl.com>; Sat, 27 Jul 2019 13:45:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=nQ09FXpb; dkim=pass (2048-bit key) header.d=kitterman.com header.b=o06TAzWN
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 SRgkJWfLfr0M for <dmarc@ietfa.amsl.com>; Sat, 27 Jul 2019 13:45:30 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D812D120075 for <dmarc@ietf.org>; Sat, 27 Jul 2019 13:45:29 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id CCD52F8071A for <dmarc@ietf.org>; Sat, 27 Jul 2019 16:44:58 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1564260298; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=0WQ7yBiKhI1PGDC7nNuB3yFDW3ZMxI5y4lMUIEDIrq4=; b=nQ09FXpbuYLAUYHerw4bQEAuvQqShApGccXo5V/KIAwixy4RvncD2VD+ a+0KSkTSNhziyU7Q6p9CVTpOXFe+CA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1564260298; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=0WQ7yBiKhI1PGDC7nNuB3yFDW3ZMxI5y4lMUIEDIrq4=; b=o06TAzWNw+kOoWQBU0EnWsNKIcOq+EZh/ine8GX/XMP0L5TTQ+aWaPGl e7r4U0pSFXHj0pwV0LvgpUPJVePRAX+GnbCeBOnZ4nFCUEVjfc1fkOkJ6W rkhGwBv9MQWQpOaov2Z2yGxdT3v/+17321SPBrRlmNRJAXWxUdIKTPHY2e NL+v6/vfrNaWGIV0nMK6b1pJ8ItICdeb3jI6QSNSpu6oshWT3VxUIySxTR KIh/8pv8A6Vq86DiKYFuDDYameM0rBBzblGFTMKqMT5cuvDio2i0S6wqzW 6emkL887gk7SwlMuzQRp/HaMl+1CCr/Ken1nhfK1s0SYmi+VYqTLLg==
Received: from l5580.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 8FE0FF80096 for <dmarc@ietf.org>; Sat, 27 Jul 2019 16:44:58 -0400 (EDT)
From: Scott Kitterman <sklist@kitterman.com>
To: IETF DMARC WG <dmarc@ietf.org>
Date: Sat, 27 Jul 2019 16:44:58 -0400
Message-ID: <4195597.6UoUMpgHb9@l5580>
In-Reply-To: <CAL0qLwaB7K3ro_=d9bfiLTYnAnNTKSQ3g10USmjADQAoYg4bPg@mail.gmail.com>
References: <CAL0qLwaB7K3ro_=d9bfiLTYnAnNTKSQ3g10USmjADQAoYg4bPg@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/cwrvhRi6IdXPBJnxHeL6OG1w0mQ>
Subject: Re: [dmarc-ietf] draft-ietf-dmarc-psd review
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: Sat, 27 Jul 2019 20:45:34 -0000

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:dmarc@dmarc.service.gov.example"
> 
> 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