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

Dave Crocker <dcrocker@gmail.com> Thu, 25 February 2021 14:13 UTC

Return-Path: <dcrocker@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 F12BE3A1A5A for <dmarc@ietfa.amsl.com>; Thu, 25 Feb 2021 06:13:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-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 mYFIY9Lo06RL for <dmarc@ietfa.amsl.com>; Thu, 25 Feb 2021 06:13:29 -0800 (PST)
Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 631723A1A58 for <dmarc@ietf.org>; Thu, 25 Feb 2021 06:13:29 -0800 (PST)
Received: by mail-ot1-x330.google.com with SMTP id f33so5744716otf.11 for <dmarc@ietf.org>; Thu, 25 Feb 2021 06:13:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=3fW8n+4OffSs+d6s2K7bFd4gR2RlNMN5pGw818cYFo0=; b=X94CsM5JeEjWc74HfJ5C4R+uLjfwwlF6u95bksTKJaP+ZHs1VO/pEnu7txAVexIduL akd28b/x+euTZ8NOM0QFeC/Fmcteh6kiyQIlDosxbUcVfFtVvHMqDqoWfjLgLXdsBp0+ ++ZlNWvECSdRRe0M8L9J28HB4MW9qyrWegGyPBYxu2Z0PrQuah5bIYr3BEWSsGShs19p cnsk7DBjgWCWpalMcS0np4p883VcHJxrBw6tS+A+/9eq7ThB7Jo53f3YgkvPKtJm+cP8 1jz1H2IZbqZozmPzH3xBbyW3zO1PutuRPQEMGOgBxLmQl1Oqv2RnK3vjrHECpK0jod3h AFog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=3fW8n+4OffSs+d6s2K7bFd4gR2RlNMN5pGw818cYFo0=; b=ujV8AajmpB9EyCGMHnXz0TX/Dmi1jgogy/fOfPXZKbe+TgH9wd8I5q3p3TaoyvMWMK r2u11UqNQUnQ+W5wnzIQ5eKRVXLBBjjC8XJxsxZna7aHjtiU1zxu2FCnWIAisPedo2EE aeyEdZ2t66la5AbXU8WtuzQP6AlS0Wtyc3vJb/po5Qp7EyBeqzRpMFG8FR39Famt3RrO 8W2TFpwvJTI7RELpxbZFJdiTj/eq7+aBq42HvsrRWY9DMVn0J9koigAq8fdAKNF5QGpz M5z35cg1GgPIPXI9qW0aknglJ45v87Y8KqWZyWsopxPsKMUfZ34H3NjOENq5HRQZRCUJ Hlng==
X-Gm-Message-State: AOAM5329IrMtynl5nUnoDVd6aysLoDRAMlUNTHeZ9bulRonojySj8lTF +BRjLq+baZihGs2LiQOQbUmb0368eBgxJw==
X-Google-Smtp-Source: ABdhPJxWFTsIttt9svrON1GvJPWPwEPqj9o+pKFKnQXx3cHsNqbvxYJ05V+xlivAr173LB7+rhTqmA==
X-Received: by 2002:a05:6830:1d43:: with SMTP id p3mr2481467oth.184.1614262408500; Thu, 25 Feb 2021 06:13:28 -0800 (PST)
Received: from [192.168.0.102] (108-226-162-63.lightspeed.sntcca.sbcglobal.net. [108.226.162.63]) by smtp.gmail.com with ESMTPSA id w22sm1080206otm.73.2021.02.25.06.13.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Feb 2021 06:13:27 -0800 (PST)
To: Barry Leiba <barryleiba@computer.org>
Cc: IETF DMARC WG <dmarc@ietf.org>
References: <161144436332.13490.10651420808048876097@ietfa.amsl.com> <CADyWQ+EhD0nz71dLtUFwb9V_6uuen-k6E5fpvrCg3ZYzfr2JSw@mail.gmail.com> <ba38a9e4-7f43-c747-2d90-f35de22a8399@gmail.com> <CAL0qLwZJaEBrXdE9JOZNOJAgR7iEzfMA86Csi2sNtE5JC7ROUQ@mail.gmail.com> <c5cd9239-b204-255a-48a3-1cdccf18464a@gmail.com> <CAL0qLwYrcg__sewPO+EWfJf-5uoHcnQpFqtw-QoXxngHTJvkAA@mail.gmail.com> <CAC4RtVDCeFQU9RTN6osPTrMpap-Djkx5+Czx=-nKqVeXnyEy1Q@mail.gmail.com> <CAL0qLwZXkRMLXS7mt28-vEKKk4HgWkP98P8kdYaS1XbcYQvSxQ@mail.gmail.com> <CALaySJLVGhaBhrmDSYayYrcU9JSq_pY6D8=KoirUGCrOeKeHCQ@mail.gmail.com> <CAC4RtVARxfJNUs+ve1ViDTF385QjLoyhw8JyKc-nALhuu=xoPA@mail.gmail.com>
From: Dave Crocker <dcrocker@gmail.com>
Message-ID: <81c05041-a4ad-a473-701c-0027cd503696@gmail.com>
Date: Thu, 25 Feb 2021 06:13:24 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0
MIME-Version: 1.0
In-Reply-To: <CAC4RtVARxfJNUs+ve1ViDTF385QjLoyhw8JyKc-nALhuu=xoPA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/W0eZBGE1cPHktPrViLeDbwTvf0o>
Subject: Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.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: Thu, 25 Feb 2021 14:13:31 -0000

If everyone liked using the PSL and making it integral to DMARC, then 
that would be fine.  But they don't; so it isn't.

The suggested revisions to Barry's suggested revisions, below, primarily 
serve to reference the PSD construct without needing to reference the 
PSL.  And, of course, there are various other suggested wording tweaks...


On 2/24/2021 9:10 PM, Barry Leiba wrote:
> — Abstract —
>
>
> NEW
>     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 uses a Public Suffix List (PSL) to determine what part of a
>     domain name is the Public Suffix Domain (PSD), below which
>     organizational domain names are created.  DMARC allows organizational
>     domains to specify policies that apply to their subdomains, but it
>     does not give that flexibility to PSDs.
>
>     This document describes an extension to DMARC to fully enable DMARC
>     functionality for PSDs.  This document also addresses implementations
>     that consider a domain on a public Suffix list to be ineligible for
>     DMARC enforcement.

The major intention is removal of reference to /how/ it does the hierarchy distinction.  In case it ever uses a different mechanism that people like better...

EVEN NEWER
    Domain-based Message Authentication, Reporting, and
    Conformance (DMARC) permits a mail-originating
    organization to express domain-level policies and preferences for
    message validation, disposition, and reporting, which a mail-receiving
    organization can use to improve mail handling.

    DMARC distinguishes the portion of a name that is a
       Public Suffix Domain (PSD), below which
    organizational domain names are created.  The basic DMARC capability allows organizational
    domains to specify policies that apply to their subdomains, but it
    does not give that capability to PSDs. This document describes an extension to DMARC to
       fully enable DMARC
    functionality for PSDs.

    Some implementations of DMARC consider a PSD to be ineligible for
    DMARC enforcement.  This specification addresses that case.




> — Section 1 —
>
> NEW
>     DMARC as specified presumes that domain names present in a Public
>     Suffix List (PSL) — Public Suffix Domains (PSDs) — are not
>     organizational domains and are thus not subject to DMARC processing.
>     In DMARC, domains fall into one of three categories: organizational
>     domains, sub-domains of organizational domains, or PSDs.  For PSDs,
>     policy can only be published for the exact domain: no mechanism is
>     available for PSDs to express policy or receive feedback reporting
>     for sub-domains.  The lack of such a mechanism allows for the abuse
>     of non-existent organizational-level domains and hampers
>     identification of domain abuse in email.

EVEN NEWER

NEW
    In the basic DMARC model, PSDs are not
    organizational domains and are thus not subject to DMARC processing.
    In DMARC, domains fall into one of three categories: organizational
    domains, sub-domains of organizational domains, or PSDs.  A PSD
    can only publish DMARC policy for itself, and not for any sub-domains under it.
       In some cases, this limitation allows for the abuse
    of non-existent organizational-level domains and hampers
    identification of domain abuse in email.




> — Section 1.1 —
>
> OLD
>     As an example, imagine a country code TLD (ccTLD) which has public
>     subdomains for government and commercial use (".gov.example" and
>     ".com.example").  A PSL whose maintainer is aware of this country's
>     domain structurewould include entries for both of these in the PSL,
>     indicating that they are PSDs below which registrations can occur.
>     Suppose further that there exists a domain "tax.gov.example",
>     registered within ".gov.example", that is responsible for taxation in
>     this imagined country.
>
> NEW
>     As an example, imagine a Top-Level Domain (TLD), ".example", that has
>     public subdomains for government and commercial use (".gov.example"
>     and ".com.example").  A PSL whose maintainer is aware of this TLD’s
>     domain structure would include entries for both of these in the PSL,
>     indicating that they are PSDs below which organizational domains can
>     be registered.  Suppose further that there exists a legitimate domain
>     called "tax.gov.example", registered within ".gov.example".


EVEN NEWER
    As an example, imagine a Top-Level Domain (TLD), ".example", that has
    public subdomains for government and commercial use (".gov.example"
    and ".com.example").  The maintainer of a list of such a PSD structure
    would include entries for both of these sub-domains, thereby
    indicating that they are PSDs, below which organizational domains can
    be registered.  Suppose further that there exists a legitimate domain
    called "tax.gov.example", registered within ".gov.example".




> NEW
>     This DMARC record provides policy and a reporting destination for
>     mail sent from @gov.example.  Similarly, "tax.gov.example" will have
>     a DMARC record that specifies policy for mail sent from addresses
>     @tax.gov.example.  However, due to DMARC's current method of
>     discovering and applying policy at the organizational domain
>     level, the non-existent organizational domain of @t4x.gov.example
>     does not and cannot fall under a DMARC policy.

darn.  couldn't find anything to suggest changing for this one...


d/

  

-- 
Dave Crocker
dcrocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org