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

"Murray S. Kucherawy" <superuser@gmail.com> Thu, 09 April 2020 20:36 UTC

Return-Path: <superuser@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 DDA953A0DDF; Thu, 9 Apr 2020 13:36:26 -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 sGVX7YzIu-QP; Thu, 9 Apr 2020 13:36:20 -0700 (PDT)
Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 B29C13A0FB6; Thu, 9 Apr 2020 13:35:58 -0700 (PDT)
Received: by mail-vs1-xe2d.google.com with SMTP id h189so110311vsc.13; Thu, 09 Apr 2020 13:35:58 -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=msbmiiaKTT/+t1DfFqpYCSgWnUV33m2GnQDvvNPkhxM=; b=TJh0MFWEr9Ehdv5ucIXcPQ05Tg1yK6tIBUTgjJ/xcIKuPBcXhOrNRorNFrF82DUWAo 6RVYwnvO3G9s93KYvZyOjUmIAKR+FpALLV2k60+Ol+W+ZhrsbwHx8oFU8YtPD/Pd2lHJ Fj4IYqdFhX4mRWeMMtzoe8rXzoSLP/6TGCh162QlUznF8+6es08p3Yi0zgidqKpExFU2 1EX0bgOMe+/n5gjLrJ5Dw84EdDvZCtByhPgX/JbJs6UQwU+Tyvq9xgkJ7iPI6DM695dy 1coWTcOmWDonu4J2q6csTzqFXpzaDBaj+nrVVxUgFBOiPAsI6eRfE5sqHPnVZ2kHu1Sa JyEQ==
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=msbmiiaKTT/+t1DfFqpYCSgWnUV33m2GnQDvvNPkhxM=; b=L6yuwlNLi9AeYSwuFjt07kMckmGP8N3X9AF60fP73Ii+WdneBlqeDFElocaDFQwTT9 ZMfJgCSZnc7RhOCsKMLS7LPL51/d8Y7cbTxJ62a3E0CSbZcAIrTPlUktw1GvAsDxisHV 35qEQ1psjOMUjE0RMaTg5oh8W+bHLuY255Iyz7kN/5xK0bHtyNO/hvZLkDc4uxuxonIb X+8HVI/up2RLF3wHBz33T195XJ2zUvtA4i7OAnRG3m6oPvNuD+fZRTRES5jTa0Q3wdvj uCzbKhCW61gx1Iq3K7IMO/eGLGFi6rNQGcfgo6oxA5sZf448b+gFcOmjqOORvmiNhSq9 rxew==
X-Gm-Message-State: AGi0PuZOqzckirOHXoqWbzqfFIlHUGpA6FE6B3a/X/PZGXCEuXfpQf6H xjqshjaf9PFfd8NKQhO4t5Mw6JjuESy6viLtcsQ=
X-Google-Smtp-Source: APiQypJ/AnJrh9NjjQ9+SJldt+6LGfvWjqL/j3gnKWfzFQ6i7qTJy0MmD02pDqkJ/cNxTa8j6swBGMVCZBDP1OtX0dY=
X-Received: by 2002:a67:804a:: with SMTP id b71mr1524595vsd.175.1586464557329; Thu, 09 Apr 2020 13:35:57 -0700 (PDT)
MIME-Version: 1.0
References: <158613543159.15216.5517593808552135017@ietfa.amsl.com> <CA+Wg=gt1SMO0n9pLOY_CKemEHimr+mnWCpNcoJWq+Da9Np7UuA@mail.gmail.com>
In-Reply-To: <CA+Wg=gt1SMO0n9pLOY_CKemEHimr+mnWCpNcoJWq+Da9Np7UuA@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Thu, 9 Apr 2020 13:35:45 -0700
Message-ID: <CAL0qLwbpSLCqe05ctGfHRS3NCH+XN51-XKYt376avf5i19JJUA@mail.gmail.com>
To: Todd Herr <toddmherr@gmail.com>
Cc: Dale Worley <worley@ariadne.com>, General Area Review Team <gen-art@ietf.org>, dmarc <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006376a405a2e190b6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/2mziPpyMZGNOK72gKuxALKH5LBg>
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 20:36:27 -0000

(Reducing Ccs)

That seems like it paints a much clearer picture, which is what Dale was
after.  A great start!

On Thu, Apr 9, 2020 at 12:54 PM Todd Herr <toddmherr@gmail.com> wrote:

> 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
>