Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-11.txt

Tim Wicinski <tjw.ietf@gmail.com> Sun, 21 March 2021 22:04 UTC

Return-Path: <tjw.ietf@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 AC2DB3A0FF6 for <dmarc@ietfa.amsl.com>; Sun, 21 Mar 2021 15:04:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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, 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 AyuxxEmpzVNk for <dmarc@ietfa.amsl.com>; Sun, 21 Mar 2021 15:04:01 -0700 (PDT)
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 3EC063A1001 for <dmarc@ietf.org>; Sun, 21 Mar 2021 15:04:01 -0700 (PDT)
Received: by mail-ot1-x334.google.com with SMTP id t23-20020a0568301e37b02901b65ab30024so14093018otr.4 for <dmarc@ietf.org>; Sun, 21 Mar 2021 15:04:01 -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=/aNo/MmlFeKWP160r8aFrjwj/M3m50TAyyiqkfYt9VQ=; b=C3Ms9SnpAWSW4SkP3bwyLCNd7uUoISfiUvrww7ek1bagetF8eZO2+4RAct0/Yev4sl NNynSdhVWG1l+LYr0rFy+2QcP+uSNeBP2hVrNqMo/k3t6Q2QMBTQKQ4i+qT21WiuN3rM 6ASn72d68PR/dDL8JCD+Err2YbOWreoOXIbu+wDz7HU58drnRj1zR0wADSZdDwWx1KG3 if0LuDADiYFaadUQl/oNbUYTDOwfB3QB5Ud2b2p5tzzqDXsTZKFXK9qGoD6r5KpkHv1w r6213gNvQh1Prpf+jN/InfM/kjEaeFqOaedNgoQsw9TyRllIAZd3XF6W6Z+i/cEKq9bH 4zdg==
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=/aNo/MmlFeKWP160r8aFrjwj/M3m50TAyyiqkfYt9VQ=; b=b+saJ92SlMsg5SPXPUIAg5gYYnznQS87W7DDR/jqfgNmtmMPW49GeRB2Tyrw2M5DA3 7Z2hwU7eZ8hJuiUkglq6BzFWb4l70+SmMrOKxiRNJcCgwO7h3T2/wI2YjIDlMoBOk75f nPigSjUz3nymIqHMKlnJJrSHpXiBo34eOIRWAtBd3STSqnKCoV97f25l4KopLyoxwzp/ kF3Zz4GTUFl6btkVwbni+m2t2djR4n++97L7Td3SSICnpEFstz8QzM6JqmOT2e0Unyxe xgw849PVkBzUBaDrZb3do80ABI0XnbwHl2epzQ3NaM+V51eAGmN2RilGjHJR+eBuEUkt J4GA==
X-Gm-Message-State: AOAM532PjDuHZqMgsNRO5z2RjmxjW7MgaMXByEUD+klV0Ez9DLXpg4QM N2F6qdkRcf8iy+jfavoVMvBpXw81xm+njUsm7jS6tzXdIP4=
X-Google-Smtp-Source: ABdhPJzN+UQnmuJuRhIHXZjnFIA/rttWFl60KqTtRPzWdliAqAlP20UtXPpcT6y5q8VyBHULU1CelD/hWlojnInemkQ=
X-Received: by 2002:a05:6830:140e:: with SMTP id v14mr9364768otp.155.1616364238493; Sun, 21 Mar 2021 15:03:58 -0700 (PDT)
MIME-Version: 1.0
References: <161616297099.26288.5532647192522385084@ietfa.amsl.com> <b6acffdb-9700-b078-6cd2-e76d7f677f32@tana.it> <CADyWQ+Gvu3Nw0kMLkJ=kAVZkG+yf-Zo+nJ+PwL0pekXcG7TDbw@mail.gmail.com> <27e3365b-0e7f-f6c1-b702-ab9ab4ba8379@tana.it>
In-Reply-To: <27e3365b-0e7f-f6c1-b702-ab9ab4ba8379@tana.it>
From: Tim Wicinski <tjw.ietf@gmail.com>
Date: Sun, 21 Mar 2021 18:03:47 -0400
Message-ID: <CADyWQ+FPuCSEiLtD9sOWAcjngRteyfYCDHt_6ftCpcxtYagUKA@mail.gmail.com>
To: Alessandro Vesely <vesely@tana.it>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000435ab805be132095"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/p4fjzO6A35dqjeLzl_4b09cvgSo>
Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-11.txt
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: Sun, 21 Mar 2021 22:04:07 -0000

All

Alessandro had some very good suggestions, but I was looking at the
document,
there were a few other mentions of PSL and I wanted to think it through.

I have some suggested text I'd like to hear some feedback on.

First though, in going over the document again, I also
found where the word "from" was repeated twice in Appendix C.2,
and I updated the reference to RFC5226 with RFC8126

---


In the Introduction, the suggested change is

OLD

   To determine the organizational domain for a message under
   evaluation, and thus where to look for a policy statement, DMARC
   makes use of a Public Suffix List.  The process for doing this can be
   found in Section 3.2 of the DMARC specification.

NEW
   To determine the organizational domain for a message under
   evaluation, and thus where to look for a policy statement, DMARC
   makes use of a public suffix list.  The process for doing this can be
   found in Section 3.2 of the DMARC specification.  Currently the
   public suffix list being used is the most common one that is
   maintained by the Mozilla Foundation and made public at
   http://publicsuffix.org [1].

The document never points to the current PSL, only to 7489. What I'm adding
is more informative to assist folks reading this who are not immersed in
DMARC.

OLD

   This document specifies experimental updates to the DMARC and PSL
   algorithm cited above, in an attempt to mitigate this abuse.

NEW

   This document specifies experimental updates to the DMARC
   specification cited above, in an attempt to mitigate this abuse.

In Section 1.1 "Example"

OLD

   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.


NEW

   Defensively registering all variants of "tax" is obviously not a
   scalable strategy.  The intent of this specification, therefore, is
   to enhance the DMARC discovery method 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
   specification.


In section 1.2 "Discussion", this will change.

OLD
   o  Branded PSDs (e.g., ".google"): These domains are effectively
      Organizational Domains as discussed in [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 purposes.

NEW

   o  Branded PSDs (e.g., ".google"): These domains are effectively
      Organizational Domains as discussed in [RFC7489].  They control
      all subdomains of the tree.  These are effectively private
      domains, but listed in the current public suffix list.  They are
      treated as Public for DMARC purposes.


In Appendix B.3, the "PSD Extension" is slightly changed.

OLD

   [psddmarc.org] provides a PSL like file to facilitate
   identification of PSD DMARC participants.  Contents are functionally
   identical to the IANA like registry, but presented in a different
   format.

NEW

   [psddmarc.org] provides a file formatted like the Public Suffix List
   (PSL) in order to facilitate identification of PSD DMARC
   participants.  Contents are functionally identical to the IANA like
   registry, but presented in a different format.




----

Welcome feedback

thanks

tim



On Sat, Mar 20, 2021 at 7:41 AM Alessandro Vesely <vesely@tana.it> wrote:

> On Sat 20/Mar/2021 01:38:40 +0100 Tim Wicinski wrote:
> >> NEW
> >>      o  Branded PSDs (e.g., ".google"): These domains are effectively
> >>         Organizational Domains as discussed in [RFC7489].  They control
> >>         all subdomains.  These are effectively private
> >>         domains, but listed in the Public Suffix List.  They are treated
> >>         as Public for DMARC purposes.  They require the same protections
> >>         as DMARC Organizational Domains, but are currently unable to
> >>         benefit from DMARC.
> >>
> > Hmm, "Public Suffix List" is in this paragraph.  Needs rethinking.
>
>
> Oops, I missed a couple of those "Public Suffix List" entries.  That term
> was
> where the conundrum stemmed from, possibly because we're unsure how much
> we
> want to bind DMARC to the only PSL implementation we know.  That's why we
> want
> to avoid that term.
>
> OTOH, the term "Public Suffix Domain" (PSD), seems to be sound.  It is
> often
> defined as "a domain under which multiple parties that are unaffiliated
> with
> the owner of the public suffix domain may register subdomains."  We can
> say
> that a domain "formally is a PSD" rather than it "is listed in the PSL".
> The
> faint semantic difference between the two phrases is the source of the
> conundrum.
>
> Being a PSD refers to a kind of contract.  ICANN mentions the above
> definition
> in a Policy Update issue[*], referring it to an expired IETF draft.
> Should our
> I-D include such a definition?
>
>
> Best
> Ale
> --
>
> [*]
> ICANN Policy Update | Volume 15, Issue 5 | Pre-ICANN53, June 2015
> https://www.icann.org/resources/newsletter/policy-update-2015-06-16-en
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>