Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

Dave Crocker <dcrocker@gmail.com> Thu, 05 September 2019 20:22 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 C45151207FF for <dmarc@ietfa.amsl.com>; Thu, 5 Sep 2019 13:22:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 JFYajjBh4QYn for <dmarc@ietfa.amsl.com>; Thu, 5 Sep 2019 13:22:33 -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 ED775120271 for <dmarc@ietf.org>; Thu, 5 Sep 2019 13:22:32 -0700 (PDT)
Received: by mail-ot1-x334.google.com with SMTP id 100so3587259otn.2 for <dmarc@ietf.org>; Thu, 05 Sep 2019 13:22:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=fa/qTiPBv7AJRvhVbDKScWjOMzsLzobmyq7GLbdLxJw=; b=R/4aUMle0QsJ7lLBzoBCCxx4MSD/Lpy6P5PNWztV7fITxgzBf0Rj+pQa8Y4I0PwgWm rScMrSjrSmsOIK8Ovk27oYQAAWE+G1vyKEMVVlRi5YwYGZy4BsLb6hYGKtQmxBY05O4c YgUNVs4pTG2V75vGsoEfV2g84rSxXeP7F1iRax/wU7f2CJCLKiUjYTAjbjHmTQHHtFBT V2PMbF9Ydq4+epxp5/HtPbUmGQRf0LJyDWtZJ9w4HjrjTkkmvAxZ2A24XdrZiw3cTeQF M0OGWek/N97iz7u7vDh7cN526e26qkLlkQVIX7cjudmj+KcNogurPmDUaRYNggWO7wjO XT3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fa/qTiPBv7AJRvhVbDKScWjOMzsLzobmyq7GLbdLxJw=; b=C14ZU1+jpYCIUP3F3OIrcy7FcsniTWVLMkozPJDInM7nTLx/Q4DgPNOvI+ogLRRjfk tU0oOcykXdmzTXLRnAaUu1DhxaEmSMYGgjNRaVmtpTUgAmTnE3LOKtEwgRwFiPaB/A0Z StqM4+nl2W4/IWIAcqkMITdqL/JwUscN9scH8dJ6TMtCSXNPIxZdsQHwaeFJZ6OFOM+B DPLBDP6w/w+2a6ARNuGzSpaCc9pQh0OCL/EViVEp5w1eaIbAqzG9HAKCyFrd6LY0nWfv bj4ArkuOZerEa8e/DznM6xHaCL2JSIaqVuPZCQIQfynu+kAdGOSvN8neix3C9p8fp3gO 9JgA==
X-Gm-Message-State: APjAAAUQfbYfgr9LwwQWlWihsUc+SMdmJa9Iszsa8HLboRtzVYRt+iin zuHVRBsc/KGm0tck5ShgTvlW7BbY
X-Google-Smtp-Source: APXvYqxGcgUUUff1nFtGbAj8t5r7GYG3g79p2PSA3IpgVQsN9wiBKg5DNBBCq06JrtJUlHQ3QzZmWw==
X-Received: by 2002:a9d:5e11:: with SMTP id d17mr4434603oti.135.1567714951804; Thu, 05 Sep 2019 13:22:31 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:d981:1a68:7c5f:511c? ([2600:1700:a3a0:4c80:d981:1a68:7c5f:511c]) by smtp.gmail.com with ESMTPSA id e22sm1067676otl.33.2019.09.05.13.22.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Sep 2019 13:22:30 -0700 (PDT)
From: Dave Crocker <dcrocker@gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <CAL0qLwacbAT04tckpPcRcnOt=1QByOBeJ7uDf6rNK6NRwtxZYg@mail.gmail.com> <ffa2bf72-3024-237b-86ae-9cc04babeec6@gmail.com>
Message-ID: <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com>
Date: Thu, 05 Sep 2019 13:22:27 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <ffa2bf72-3024-237b-86ae-9cc04babeec6@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/kgTog3qqI0xUQfP2uv-2iszygQM>
Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
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, 05 Sep 2019 20:22:35 -0000

On 9/4/2019 6:28 AM, Dave Crocker wrote:
> ence my current view that:
> 
> 1. The change to DMARC should be limited to permitting the query for the 
> organization domain to be anywhere in the DNS tree, including a TLD. 
> Within DMARC this would not look like 'extra' mechanism.
> 
> 2. The mechanism that processes that query should be cast strictly as a 
> PSL enhancement, independent of DMARC.


Trying to refine things further:


    DMARC does not care about the PSL.

    What DMARC cares about is the Organizational Domain (OD), as a 
fallback when no DMARC record is found at the desired domain name.

    That is, PSL is literally outside the scope of DMARC.

    At the least, therefore, the DMARC specification should define a 
distinct interface to the outside functionality that tells DMARC where 
the OD is, which will return what suffix of the full domain name is the 
OD --  eg, getOrgDomain(full-domain) -> org-domain-suffix

    The PSL-related side of that interface should be a separate 
specification, so that changes to its behavior -- such as has been 
happening with the introduction of ODs that are TLDs or are otherwise 
'above' where DMARC has been guessing the OD to be -- are isolated from 
DMARC.

    The current problems are that DMARC has embedded too much detail 
about the PSL world, yet DMARC has no involvement in that world. The 
current proposal embeds assumptions of PSL knowledge further, rather 
than separating PSL knowledge out.


d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net