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

"Stan Kalisch" <stan@glyphein.mailforce.net> Sat, 27 July 2019 22:00 UTC

Return-Path: <stan@glyphein.mailforce.net>
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 6B6CC12008C for <dmarc@ietfa.amsl.com>; Sat, 27 Jul 2019 15:00:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=JdSU0m7a; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NeBQ5lC+
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 g15u6oQ7nobo for <dmarc@ietfa.amsl.com>; Sat, 27 Jul 2019 15:00:38 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5F7B12007A for <dmarc@ietf.org>; Sat, 27 Jul 2019 15:00:37 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id CBB5621B1B for <dmarc@ietf.org>; Sat, 27 Jul 2019 18:00:36 -0400 (EDT)
Received: from imap6 ([10.202.2.56]) by compute7.internal (MEProxy); Sat, 27 Jul 2019 18:00:36 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=gOYazr+ea+2q0+bHi6hkrSSufd6LLMn gSVDov/2wEIE=; b=JdSU0m7aYjF+3ScQ7xxwNSH6zaZppiuaZIQmJYK+CKvXF41 T4ydjTIju1peBX9fLk7my00OVFIF1FvzqEDB3sM+IkUNaqP2e9eJoDJhYv8YA/uU 34ma25ZA1CHK6P6bsLTZghmgwiU04ifkBcyluhoA58cGE7VpeXQB72K1TzrLxvXi aMTrlYuLIcclcmZ9eUx2bK8hTUX4gKuY+scDk5pQ/u33xxbj2TDA6RfRxi9sfPK7 Sn0eBIxCoaP1GCl41EJEneQ23ojUkNk4/0QLINN6pjuKctJEUJg9WwysCSvlceYO 41s+BGUVRnm/GJ+RpYeU/RaxLU/HhoWfx1slfXg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=gOYazr +ea+2q0+bHi6hkrSSufd6LLMngSVDov/2wEIE=; b=NeBQ5lC+aoQpN/elH33e7g mHH8Ndtlfkh+NBsdB7RtwDS819tfJQSO2/a742JfWdgJrAhChC0ao+bM1xHxd9b6 oDzM4S8MTnsO87iTzdgV8sFA7T8Z4/CwGOnUQRKPuDLSHdtwM/hZWY8TsDwikuT1 mkpC2lEi/bWvtrTNxnA2raNdUUPjD81T2WGrtj/LC5yPcCAjMSKZmj4uUCrFvh50 cHLTSP6qJmYLjHdswv4RnbT26szX2oG1IIbhwD9mPqU3WuMDc5NOfrSa0e5mDgia TmDNV4O+FmHDw0kjMMBg6ZshYEM7BYFHgdLGo9IV5aetjhHNs4rx1KBJ46V/+XDQ ==
X-ME-Sender: <xms:hMk8XZjt3dRMqKXiFm4C6eQ67e7cUHB1PtoOA6G5rKmSTmaSlJg5_Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrkeeigddujeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfufhtrghnucfmrghlihhstghhfdcuoehsthgrnhesghhl hihphhgvihhnrdhmrghilhhfohhrtggvrdhnvghtqeenucffohhmrghinhepihgvthhfrd horhhgpdgrnhgurdgtohhmpdgvgigrmhhplhgvrdgtohhmpdgvgigrmhhplhgvrdhithen ucfrrghrrghmpehmrghilhhfrhhomhepshhtrghnsehglhihphhhvghinhdrmhgrihhlfh horhgtvgdrnhgvthenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:hMk8XdPU363V_JtRBiM4QvinfKDCNximUqz_Ec_VWP18s422ru-dvQ> <xmx:hMk8XbyaOAuwL4taxF1ER1wBjZnK2_ErJyflr9NqCHVOTBc4DSFepQ> <xmx:hMk8XXoDwBdgLHpMv3VHNdTbaAmGnPsSrQ7fJlkd200NKIGPThHW7g> <xmx:hMk8XcBdi0c87uOjJu6Olc5cuwr4akqxxMAKquCXTuVtRESP5XETAg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 57B91140169; Sat, 27 Jul 2019 18:00:36 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-736-gdfb8e44-fmstable-20190718v2
Mime-Version: 1.0
Message-Id: <9c3e075d-1a01-4b97-9626-231508104335@www.fastmail.com>
In-Reply-To: <4195597.6UoUMpgHb9@l5580>
References: <CAL0qLwaB7K3ro_=d9bfiLTYnAnNTKSQ3g10USmjADQAoYg4bPg@mail.gmail.com> <4195597.6UoUMpgHb9@l5580>
Date: Sat, 27 Jul 2019 18:00:30 -0400
From: "Stan Kalisch" <stan@glyphein.mailforce.net>
To: dmarc@ietf.org
Content-Type: multipart/alternative; boundary=aa803c8efbd44b13a2153b92c1e8743a
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/mCdTL1UgDg3rohav3hkvM02qz-g>
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 22:00:42 -0000

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: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
> 
> 
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>