Re: [dmarc-ietf] Genart last call review of draft-ietf-dmarc-psd-08

Todd Herr <toddmherr@gmail.com> Thu, 09 April 2020 19:54 UTC

Return-Path: <toddmherr@gmail.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 7D69A3A0D12; Thu, 9 Apr 2020 12:54:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 WR7rJ5WuDdfK; Thu, 9 Apr 2020 12:54:16 -0700 (PDT)
Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6056D3A0D0C; Thu, 9 Apr 2020 12:54:16 -0700 (PDT)
Received: by mail-ua1-x92e.google.com with SMTP id o14so437982uat.13; Thu, 09 Apr 2020 12:54:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cdDwdDANnFtMMko1tWuxOAyblzuzcBUj4HcMEs+pQlw=; b=TymQRT8IiwSJ5M8neN1J+a8eyzlv/V3140wBWXniW1MJW+f7VLL7Z6BomXo6/0YiaF JuLE68UX6U0S/y6yPBjl40XFU/4rNFuzSskio5BOq4YTsNBZd7IWfWioM5hu+eB5/g4Y hjbcY8Ok+EyoeIiPabW+dP9nwXO+P/E2+hdtMpdRQxjYXLuhQ1OxJOhQ1z97yBaalALp uYi2GZ3XNPoV/L6vPnb74t1j4u0WRErpUzyBTFH1N7UuajTPzfYn6M9KlCI1Y7WNT3NU O3PNZCnSbxTZ/LJrJ73ovXH+eIkO36/cOftqmEmDoYXwJNqLOFzAaIJmEFpF8+CVZZZo h1Cw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cdDwdDANnFtMMko1tWuxOAyblzuzcBUj4HcMEs+pQlw=; b=k7Wur1t9IyilGocU6BBnQX1m/M6ldJ1TKxVmhGiPDSwQP0MvLdRKuIwaJM3PBWfLqJ y43oUNNCCY4/XlTD9WvvR61q6MrffrJjFgAjDjVNS1s9rOnmwZ49K4NUnt/VJJeQWDL9 Pprm49racY2eT0bhBOeqC7d/hi2rbUg66mkPPq+/sdL/yakJ+jINVooFn8OrwBd4paLS ewVt6MC6VECG4ZPjRUbFYB7D3QXUk8ZOzaXrfwumlhE2d2utwZXiaDVCcTsGbmA6O+FX kcvf+YX3AbEgC3y/wCPmh7UvTDl4saOaIdsRCxzapf2WVYymIhemqp0V25gOKnz3911M pR/Q==
X-Gm-Message-State: AGi0PuZ4SzN7Qby1RYhLjxmyOLPm+uT3UbJTawmir3x8SzOGDJWr0x2A Ip/5M2HJ2b7d8uQcZOSY1brg0XNVposi/NXRiJ9ncVAB+MI=
X-Google-Smtp-Source: APiQypJdq8c9AbJzxN5687LrzTl8uahIr2ZyolWNsQPxmTHnqKlkyGt9ZkM0H19M6m40tAoaTg0eLfMmMskVTmw8SNA=
X-Received: by 2002:a9f:2102:: with SMTP id 2mr700517uab.41.1586462055243; Thu, 09 Apr 2020 12:54:15 -0700 (PDT)
MIME-Version: 1.0
References: <158613543159.15216.5517593808552135017@ietfa.amsl.com>
In-Reply-To: <158613543159.15216.5517593808552135017@ietfa.amsl.com>
From: Todd Herr <toddmherr@gmail.com>
Date: Thu, 9 Apr 2020 15:54:02 -0400
Message-ID: <CA+Wg=gt1SMO0n9pLOY_CKemEHimr+mnWCpNcoJWq+Da9Np7UuA@mail.gmail.com>
To: Dale Worley <worley@ariadne.com>
Cc: gen-art@ietf.org, last-call@ietf.org, dmarc <dmarc@ietf.org>, draft-ietf-dmarc-psd.all@ietf.org
Content-Type: multipart/alternative; boundary="00000000000040a80105a2e0fb29"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/kWNHLp-DIHLjeRNbe2dmBVjko48>
Subject: Re: [dmarc-ietf] Genart last call review of draft-ietf-dmarc-psd-08
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: Thu, 09 Apr 2020 19:54:21 -0000

Having reviewed the comments, I'm wondering if perhaps the following draft
rewrite of the Abstract section might be a first step to address many of
the points raised?

*AbstractDMARC (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 original design of DMARC applies only to domains that are registered
with a domain name registrar (called “Organizational Domains” in RFC 7489)
and nodes in the tree below Organizational Domains. Organizational Domains
are themselves nodes in the tree below domain names reserved for
registration, with the latter commonly referred to as “Top Level Domains”
(TLDs) (e.g., ‘.com’, ‘.co.uk <http://co.uk>’, etc.), although in this
document they will be referred to as Public Suffix Domains (PSDs).*

*Since its deployment in 2015, use of DMARC has shown a clear need for the
ability to express policy for PSDs. This document describes an extension to
DMARC to enable DMARC functionality for PSDs.*

*RFC 7489 describes an algorithm for a mail-receiving organization to use
in determining the Organizational Domain of an inbound mail message, and
this algorithm recommends the use of a “public suffix list” (PSL), with the
most common one maintained by the Mozilla Foundation and made public at
<http://publicsuffix.org/ <http://publicsuffix.org/>>. Use of such a PSL by
a mail-receiving organization will be required in order to discover and
apply any DMARC policy declared by a PSD.*

*This document also seeks to address implementations that consider a domain
on a public Suffix list to be ineligible for DMARC*


On Sun, Apr 5, 2020 at 9:11 PM Dale Worley via Datatracker <noreply@ietf.org>
wrote:

> Reviewer: Dale Worley
> Review result: Ready with Issues
>
> I am the assigned Gen-ART reviewer for this draft.  The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed by
> the IESG for the IETF Chair.  Please treat these comments just like
> any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document:  review-draft-ietf-dmarc-psd-08
> Reviewer:  Dale R. Worley
> Review Date:  2020-04-05
> IETF LC End Date:  2020-04-08
> IESG Telechat date:  not known
>
> * Summary:
>
>        This draft is on the right track but has open issues, described
>        in the review.
>
> * Major issues:
>
> The privacy concerns described in section 4 are written as if there is
> no certainty that the mechanisms described in the document properly
> mitigate them.  So the document appears to be incomplete.  OTOH, since
> this is an Experimental RFC, such mitigation isn't necessary if there
> is commitment to do so later.  In that case, the section should
> explicitly state that these are open issues and that there is an
> intention of revising the document to mitigate them.
>
> The text suggests that a mail receiver(?) that does DMARC processing
> has knowledge of all PSDs.  This seems a priori unlikely and even
> impossible to implement.  So this ought to be either explained at the
> appropriate place or resolved technically.
>
> * Minor issues:
>
> The document has the (common) editorial problem that it is written by
> people who are deeply familiar with the subject, and it's difficult to
> read if one doesn't share that familiarity.  This is particularly
> significant because DMARC is an e-mail facility that (ideally) will
> affect all e-mail that is sent, so the target audience really should
> be anyone who has a basic understanding of e-mail.  Three particular
> elements of this are:
>
> - It would be very helpful if the Introduction could state, in a few
>   sentences, the purpose and operation of DMARC, thus informing the
>   reader of the framework whose deficiencies this document attempts to
>   address.  In particular, one shouldn't have to read the DMARC RFCs
>   to be able to read this document and understand its general import.
>
> - The "experiment" appendixes are unclear about what the experiments
>   actually are:  what questions they are to answer, what actions will
>   be taken, how the results will be evaluated.  Starting each appendix
>   with an overview paragraph would be helpful.
>
> - Forward references should be minimized so that a reader can
>   understand the document in one pass.
>
> As a derivative of the first of these elements, the terminology used
> for the properties of domain names is not clearly defined.  In
> particular, where does a registration "occur"?  The only term for
> which I think the general audience possesses an unambiguous definition
> is "the registered domain name", e.g. ietf.org.  Now I *think* its PSD
> is ".org", but it might be "ietf.org", and I don't know whether the
> registration of ietf.org "occurs" at ietf.org or .org.  Further points
> I didn't understand are pointed out in the review of the
> Abstract and Introduction.
>
> * Nits/editorial comments:
>
> Abstract
>
> I'm having quite a bit of difficulty figuring out exactly what the
> Abstract means.  I'm sure that the working group clearly understands
> what is meant, but the writing is just loose enough that I can't fix
> the meaning.  To raise the immediate questions:
>
>    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.
>
> This sentence is quite good, as it introduces what DMARC is all about.
>
>    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.
>
> You want to make clear here that "registration" means "domain name
> ownership registration" (which is what section 2.2 says).  Otherwise
> it leaves open that there is some sort of DMARC registration that you
> might intend, until the reader gets to section 2.2.
>
> There's an ambiguity regarding "where" a registration happens.  E.g.,
> does the registration of "ietf.org" "occur at" "ietf.org" or "occur
> at" "org"?  It's possible that this could be simplified/disambiguated
> by not using this term, but instead phrasing this in terms of domain
> names that "are registered", and the allowed relationships between
> them.
>
> And it appears certain that there are DNS nodes where registrations
> are only done *above* that node, e.g. "datatracker.ietf.org", which
> this sentence (if taken literally) says is not permitted by DMARC.  Is
> the property you want to declare "one node where registrations are
> done cannot exist below another node where registrations are done"?
>
> Or perhaps domain names like "datatracker.ietf.org" are of no interest
> to DMARC because DMARC is never applied to messages for which that is
> the relevant address?
>
>    Since its deployment in 2015, use of
>    DMARC has shown a clear need for the ability to express policy for
>    these domains as well.
>
> This sentence doesn't make it clear what "these domains" refers to.
>
>    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.
>
> It would probably be clearer to use "domain name ownership
> registrations" again here.
>
> This sentence suggests that the registration of "ietf.org" "occurs at"
> "org" and so "org" is a PSD.
>
>    This document also seeks to address implementations that consider a
>    domain on a public Suffix list to be ineligible for DMARC
>    enforcement.
>
> This suggests that implementations believe that they know of all PSDs,
> so they can "consider them ineligible for DMARC enforcement".  But
> it's hard to imagine that that they can know that they know of all
> PSDs.
>
> An additional point, and I'm not sure how valuable this is, would be
> to clarify "I'm holding an e-mail message in my hands.  What do I do
> next?", that is, What address in the message is the domain whose DMARC
> information is applied to the message?  And what indeed does DMARC
> processing do to a message?  For most of the sentences of the
> Abstract, this is not important, but it leaves the effect of the last
> sentence unclear, as "DMARC is not enforced on messages whose *sender*
> is in a PSD" is quite a bit different from "DMARC is not enforced on
> messages whose *recipient* is in a PSD".  (Section 3.3 suggests that
> the address in the From header of the message is the one that is used
> for DMARC processing.)
>
> It's unclear what exactly is the contents of a "public suffix list".
> Naively, it appears that it is the list of domain names under which
> names can be registered, but the text uses the term in the plural, so
> there must be some additional structure.
>
> Also, it seems there are some significant privacy matters addressed by
> this document, and it's probably worth adding a sentence to notify the
> reader of that.
>
> 1.  Introduction
>
> A number of the questions about the Abstract apply to the Introduction
> as well.  But generally, since e-mail is a subject that every reader
> has a basic knowledge of, it would be useful to write the introduction
> so that one did not have to have a knowledge of the DMARC architecture
> to understand the introduction.
>
>    "gov.example" publishes the following DMARC record:
>
>    "v=DMARC1; p=reject; rua=mailto:dmarc@dmarc.service.gov.example"
>
>    at
>
>    _dmarc.gov.example.
>
> Even better would be this aid to people who don't already know DMARC
> implementation:
>
>    "gov.example" publishes the following DMARC DNS record:
>
>    _dmarc.gov.example.  TXT \
>         "v=DMARC1; p=reject; rua=mailto:dmarc@dmarc.service.gov.example"
>
> --
>
>    the non-existent organizational domain of @tax.gov.example
>
> I suspect you mean "t4x.gov.example" here.
>
>    This document provides a simple extension to DMARC [RFC7489] to
>    allow [...]
>
> This sentence lists 4 important items, each of which is fairly long,
> which together are the summary of the whole document, so it might be
> useful to break this into a bullet-list.
>
> 2.  Terminology and Definitions
>
>    In many cases the public portion of the DNS tree is [...]
>
> What does "the public portion" mean?  I'm guessing it means "the names
> not available for private registration", but you should be unambiguous
> here.
>
>    They are not available for private
>    registration.  In many cases the public portion of the DNS tree is
>    more than one level deep.
>
> It seems like these two sentences are redundant and the flow of the
> paragraph would be better if they were removed. ... Actually once they
> are removed, it reveals that the next two sentences largely duplicate
> the first two sentences of the paragraph.
>
>    2.3.  Longest PSD
>
>    The longest PSD is the Organizational Domain with one label removed.
>
>    2.4.  Organizational Domain
>
>    The term Organizational Domains is defined in DMARC [RFC7489]
>    Section 3.2.
>
> 2.4 should be moved ahead of 2.3 to avoid a forward-reference.  But it
> would be really helpful if the definition of Organizational Domain was
> either summarized here or completely copied from RFC7489.  In
> particular, if Organizational Domain is not the same as registered
> domain name, that should be flagged.
>
>    2.5.  Public Suffix Operator (PSO)
>
>    A Public Suffix Operator manages operations within its PSD.
>
> Better to explicitly define the possession relationship explicitly:
>
>    A Public Suffix Operator is an organization which manages
>    operations within a PSD, particularly the DNS records published for
>    names at and under that domain name.
>
> --
>
>    2.6.  PSO Controlled Domain Names
>
>    PSO Controlled Domain Names are names in the DNS that are managed by
>    a PSO and are not available for use as Organizational Domains.
>    Depending on PSD policy, these will have one (e.g., ".com") or more
>    (e.g., ".co.uk") name components.
>
> The second sentence is odd; is it useful?  Is it just to say "PSO
> Controlled Domain Names may have one or more components."?
>
>    3.1.  General Updates
>
>    References to "Domain Owners" also apply to PSOs.
>
> This change really ought to be localized to a specific textual change
> somewhere in RFC 7489, in the say way that the other changes are
> specific amendments to the DMARC algorithm.
>
>    3.2.  Section 6.3 General Record Format
>
> These section titles are difficult to read.  At first I thought there
> was some typographical problem.  But you could clarify this as "3.2.
> Updates to Section 6.3.  General Record Format".  Similarly for the
> other subsections of section 3.
>
> 3.3.  Section 6.5.  Domain Owner Actions
>
>    The mechanism for doing so is one of the
>    experimental elements of this document.
>
> I think that what this means is that the whole document is an
> experimental "mechanism for doing so".  If so, I think it could be
> better phrased
>
>    This document is an experimental mechanism for doing so.
>
> --
>
>    3.4.  Section 6.6.1.  Extract Author Domain
>
>    [...] when the domain name extracted by the receiver (from the
>    RFC5322.From) is on the public suffix list used by the receiver.
>
> This touches the question above about what a public suffix list is,
> and how there can be more than one of them.  But without that
> knowledge, it's hard to see which PSL is "used" by the receiver of the
> message.
>
> Also, it's not clear to me how *this* document creates a capability
> which applies to domains that are on the PSL.  E.g., if an "np" is
> defined for ".org", it applies to (that is, affects processing of
> e-mail from) any "X.org" that doesn't have its own DMARC records.  But
> I don't see how an "np" tag for ".org" affects processing of messages
> from "example@org".
>
>    3.5.  Section 6.6.3.  Policy Discovery
>
>       (discussed in the experiment description
>       (Appendix A))
>
> Given that this text is nominally an update to the text of RFC 7489,
> you want to disambiguate the binding of "Appendix A":
>
>       (discussed in the experiment description
>       ([this document] Appendix A))
>
>    3.6.  Section 7.  DMARC Feedback
>
>    See Section 4 of this document for discussion of Privacy
>    Considerations.
>
> Similarly to section 3.5, but also clarifying the scope of "privacy
> considerations":
>
>    See Section 4 of [this document] for discussion of Privacy
>    Considerations for PSD DMARC.
>
>    4.  Privacy Considerations
>
>    The Privacy Considerations of [RFC7489] apply to this document.
>
> This could be clarified as
>
>    Additionally, the Privacy Considerations of [RFC7489] apply to the
>    mechanisms described by this document.
>
> --
>
>    Providing feedback reporting to PSOs can, in some cases, create
>    leakage of information outside of an organization to the PSO.
>
> "outside" probably isn't the word you want to use here, as it is
> easier to read "outside" as giving the original location of
> "information" than to read "outside" as giving the direction of
> "leakage".  Perhaps
>
>    Providing feedback reporting to PSOs can, in some cases, create
>    leakage of information out of an organization to the PSO of its
>    domain name.
>
> --
>
>    To minimize this potential concern,
>    PSD DMARC feedback is best limited to Aggregate Reports.  [...]
>
>    [...] any Feedback Reporting related to multi-
>    organizational PSDs ought to be limited to non-existent domains
>    except in cases where the reporter knows that PSO requires use of
>    DMARC.
>
> I can't see where in the document that these principles are turned
> into MUST statements that ensure the privacy issues are solved.
>
>    The experiment is to evaluate different possible approaches.
>
> Calling this an "experiment" suggests that these is an intended series
> of actions whose result will answer the listed questions.  But there
> doesn't seem to be any such actions listed.  The description makes it
> sound like what is intended is continuing discussions in the working
> group, but that wouldn't be an "experiment".
>
> A.2.  Non-Existent Subdomain Policy
>
> Similar questions arise for this section.  The second paragraph
> suggests that the experiment is to see whether the "np" tag is
> successful.
>
>    There are also
>    suggestions that it would be more generally useful for DMARC.
>
> What does "it" refer to?  (Does it mean "this ability"?)
>
> Appendix B.  DMARC PSD Registry Examples
>
> In this appendix, it appears that the contents of the experiment are
> clear in the authors' minds, but there is no summary at the top that
> states what the experimental facilities are and the "big picture" into
> which they fit.
>
> Appendix C.  Implementations
>
>    C.1.  Authheaders Module
>
> What e-mail MTA is Authheaders an extension for?
>
> [END]
>
>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


-- 
Todd Herr