Re: [dmarc-ietf] Summary comments on draft-ietf-dmarc-psd

"Murray S. Kucherawy" <superuser@gmail.com> Thu, 12 March 2020 03:37 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 98E3D3A09CC for <dmarc@ietfa.amsl.com>; Wed, 11 Mar 2020 20:37:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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 JpotGxMS44lw for <dmarc@ietfa.amsl.com>; Wed, 11 Mar 2020 20:37:05 -0700 (PDT)
Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 7CEE03A09B8 for <dmarc@ietf.org>; Wed, 11 Mar 2020 20:37:05 -0700 (PDT)
Received: by mail-vs1-xe2e.google.com with SMTP id u24so2793923vso.11 for <dmarc@ietf.org>; Wed, 11 Mar 2020 20:37:05 -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=l/u4fSVHYPHfL/sXLQE9JMJzec5hqtXbse8/pD9I+pI=; b=cng1E5mjzpV8snOLLy8naSHRwUgBZzT8XQRPWWC/ZxjwfjUkyCPw2jzrgsCHM2tRJu kuuTN9IwlNsA7QGL2agg9lIG5nJZM1mBdLen7rHnBrZjqhHEWLZYsnERuG1EgDVNGdnH qBWn6siCyQitdZMB6PNNGT/7nCPygQPUmvW2Fv18ovXdOXeI3gZYtXAbl8dRK8WycJSI fEFY5Rjg3L++eXyre22aL5Hp+YWdnxCxdHn1h/pF8cIX7mYr7aOrK/OnzTigMVIHl6Hm mnznHSoMwKwqGcXtRyZ2LF7uzmk2WLgAtVpUGNiWTgLIc4qVoJhCekBnn0b+NxNBDK8G Mthw==
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=l/u4fSVHYPHfL/sXLQE9JMJzec5hqtXbse8/pD9I+pI=; b=JGZ3IbZhwdr3ZnH2da1omV5jsedqkAak8GCx7mStqGTqVH5OPii9VmkCHp7BLstBif J2QqtOiecOK1uxZgENDLw1x+NPRSfIwgXHfubIoN/1zSdlcvKCcbRPwPYWeleqPcUVq4 80wbYASFHhmF1nAGwqGuD7KY738IwRR//B9+nDq2VQX3SsW/oBwGkNG+NS58ubFN/hj9 9GKBaPC61rBmt/04sVsYXnWoSFDELG54WaXP5Do9AE8fAwMcUvFhAOUr5D9NIGyuXpZT PJ+tBuT04HhQBIpNUgLBhRc9cBo6+IPCr0IV7RyNYb0TX/+axfOVabwjNAYDPGNkazOg dxWw==
X-Gm-Message-State: ANhLgQ3OkiS4rWH/jF61VQiaEtrtb+gThFdMNGV31x6r/KSBUFVN+krr 4DXg6ADHsCGyla7w7xdcBet+D46ReLzSvj3z++V3wQ3D
X-Google-Smtp-Source: =?utf-8?q?ADFU+vt9EUbnYSwTrE1NeIHsoyGahPCLYONHEcgB06or?= =?utf-8?q?mJ7YitaiLT48Ib6/1hOnpPxxbQCYTMf6W0Q4iyQJG5UXByY=3D?=
X-Received: by 2002:a67:c898:: with SMTP id v24mr4105503vsk.13.1583984224331; Wed, 11 Mar 2020 20:37:04 -0700 (PDT)
MIME-Version: 1.0
References: <86865bcb-0b58-f0dc-c0d5-76053ded31e2@dcrocker.net> <3996028.BDLCgmsoE7@l5580>
In-Reply-To: <3996028.BDLCgmsoE7@l5580>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Wed, 11 Mar 2020 20:36:53 -0700
Message-ID: <CAL0qLwYcPD_Aq4VotZT6MvudUYrN=0qLmVeXqE=67BDFjhaFmA@mail.gmail.com>
To: Scott Kitterman <sklist@kitterman.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000056c1705a0a0115a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/k0emYgYKkeacHbmixIy9tGG4-8M>
Subject: Re: [dmarc-ietf] Summary comments 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, 12 Mar 2020 03:37:08 -0000

As a participant:

On Wed, Mar 11, 2020 at 7:00 PM Scott Kitterman <sklist@kitterman.com>
wrote:

> > 0. DMARC use of Organizational Domain
> >
> > DMARC specifies use of the Organizational Domain as a fallback for not
> > finding a DMARC record at the full domain name under scrutiny.  The need
> > for this is to cover slow DMARC adoption among sub-domains and to handle
> > queries about non-existent domains.
>
> It also short circuits the need for a tree walk up to the organizational
> domain.  I think it's also relevant to note that it only addresses queries
> about non-existent domains below the organizational domain level.  This
> draft
> provides for an equivalent for non-existent organizational domains where
> appropriate.  It also provides for a mechanism to express a different
> policy
> for non-existent and existent sub-domains.
>

Since we're mentioning a tree walk here, I believe we are ripe for a
reopening of that debate.  It's my understanding that the DNS community has
softened its position on the impact of such a mechanism as a way of finding
nodes of interest.  I could be wrong, but there's one way to find out.
Perhaps that is the case, and that a tree walk renders many of these issues
moot.

> 1. These are not 'public' suffixes (1)
> >
> > The concept of a 'public' suffix refers to domain names associated with
> > registries subject to externally-imposed operational policies.  For want
> > of a better term, these operations are regulated.  The domain suffixes
> > that PSD attends to are not public registries.
> >
>

I suspect the name used derives from the name of the resource to which
DMARC attached itself early on, namely the Public Suffix List.  Debating
its name is probably out of scope here.  And as Alessandro pointed out, the
PSL was made for a different purpose and DMARC simply decide to use it to
meet its own goals, which in turn supports DMARC distancing itself a bit.

I believe where this is leading, though, is toward the notion that the use
of the PSL should be considered external to DMARC.  I don't think anyone
has disagreed with that assertion.

> 2. Externalizing internal difficulties
> >
> > Some organizations have sub-groups to which various administrative
> > responsibilities have been delegated.  In general, there can be many
> > levels of such delegation.  Not just two.
> >
> > For the cases the PSD specification is intended to cover,
> > PSD seeks to adapt to slow DMARC adoption or non-existent domains for
> > one of its delegated sub-groups, by looking for an even-higher-level
> > encompassing record under a next-level Organizational Domain.  That is,
> > PSD is specifying using two different Organizational Domains.  The usual
> > one and its parent.
> >
> > A difficulty within the organization is being externalized to a burden
> > for everyone else on the net.
>

Can you expand on how you see abuse of non-existent domains to be an
exploitation of an internal problem?  Specifically, what's the internal
problem being exploited?

> 5. There is little engagement with the PSD technical effort
> >
> > It is easy to see why owners of some domains would want a mechanism like
> > PSD.  As noted, they do have a real and significant problem.  So,
> > statements of support from such folk merely confirm their need.  (As an
> > aside I'll note that historically the IETF hasn't been all that
> > interested in simplistic statements of support but, rather, actual
> > involvement in the engineering discussion.)
> >
> > What such statements do /not/ provide is any indication that the broader
> > Internet community has an interest in adopting this.
> >
> > First, where are the statements of actively engaged support from an
> > interesting set of organizations on the other side of these queries?  In
> > general, there has been a track record of limited adoption for anything
> > that changes infrastructure services, in the absence of a very
> > widespread perception of need, benefit, and tractable operational cost.
>
> I don't think that accurately characterizes the situation for PSD.
>

I think there's some validity here at least in the claim that the purported
interest has not made itself both visible and enthusiastic.  Such dearth
absolutely does not rise to the level of supporting something on the
standards track, to be sure, but that wasn't the goal here either.

> 6. The 'experiment' has vague goals and criteria
> >
> > In spite of having explicit language covering this specification as an
> > 'experiment' the specification does not give me a clear and concrete
> > understanding of exactly what will be evaluated, or how, and what
> > constitutes satisfactory accomplishment.
>

As we're now under AD Evaluation and there's still an IETF Last Call to go,
this is still on the table for being fixed if it appears by further
reviewers to be unclear.

-MSK