Re: [dmarc-ietf] auth-res vs. dmarc

"Murray S. Kucherawy" <superuser@gmail.com> Fri, 01 January 2021 04:11 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 F142F3A0C03 for <dmarc@ietfa.amsl.com>; Thu, 31 Dec 2020 20:11:49 -0800 (PST)
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 3Km9pQquIC1F for <dmarc@ietfa.amsl.com>; Thu, 31 Dec 2020 20:11:48 -0800 (PST)
Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 3F0F13A0C00 for <dmarc@ietf.org>; Thu, 31 Dec 2020 20:11:48 -0800 (PST)
Received: by mail-vs1-xe32.google.com with SMTP id s2so10778281vsk.2 for <dmarc@ietf.org>; Thu, 31 Dec 2020 20:11:48 -0800 (PST)
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=UtwvjliP89wADB/WYy/CTC2AiIFLo/e3rXh3+p737wI=; b=W+IhBni8kJUhaLW7OR6xB1CpiWCobPCAqmGp0+jMXIFq2P3er2DX9rGJEF/ukt8G7m 5nZYBfPzdCmyJeg3kyArWJG5l2yG1RZEm/5Do8yN5Dygr0N3yXzf8a8Yzt9Ssv3z6uuq fnaYYZPJmCk+MIex/RWu25iRKStMntzCyRd9GsgPU/evrYgXdyAiO35YaTOFcP6RS0RS Nl/BJGnY2sMqxt+wlWdZO+HJnFMG6CCMnnOdj382X26lE3VkJj1ZL2HUQP/NwqtrV5cl PZjm58hdruVH+1V1gByta1yfK9qCOzHOVYEWASBM5YDNAhUOVFDYN8oyBJVk+PnfWfXJ Iq+A==
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=UtwvjliP89wADB/WYy/CTC2AiIFLo/e3rXh3+p737wI=; b=T4Ufm+oioB+wXjTD0Dxhp6tsnTwpvhl7C1Z5Rf6/oz7x2IOlDqi7wk4MEFZlzmC9Eu ScOlcRjtsns5qZFssOuuOPVUypg9XrJWoHs/zOE6wuJDefs+zhRNw688P5fYPwhzBapy vtpP/Ga76zIOHfPxssX2nZxqKbaffRxTbMAuRF604lVTxTi6vvHRdxYeOZdlYruKSvh6 neP84BGXhqJoMq95XTdP/xlIH10eUOvay8xKOiaIQ1iqW5of1WM4o1Bu8WlMU7Pu1qd6 m4ha5e01CLFW+JAmDUUmlZschMHE4QzycJvrunmGmzDf3RE2tSUEs9U6IGmByuvvekvL 683A==
X-Gm-Message-State: AOAM533DzNLkQIlYXcytzFP9LP6lvHUpCFU2FlPJ78DJuhXXD4Xg9nl9 r3gSoujq1oFuBOG6dO3C9wCJomtTHei7lyZqdyo=
X-Google-Smtp-Source: ABdhPJzZC8EEo0YkwnXR++fiK/FrzOJ61+UGch/h21tag3ts3SvI9lOo0iS2Gy7x4VeINSzNYvOT8EXjfWzRHc9CQKo=
X-Received: by 2002:a67:f14f:: with SMTP id t15mr38003785vsm.0.1609474307084; Thu, 31 Dec 2020 20:11:47 -0800 (PST)
MIME-Version: 1.0
References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <CAHej_8mApfoF2ORgL+DoYTanrdhMjvT9H27kORwLKCQc1C9sRw@mail.gmail.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <CAHej_8=kW_t_JkOxUud1Uz8+PrbMh5CfwfxZK=mhe0wjW8wQpw@mail.gmail.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <CAHej_8kCi=7oqojDH_rbjn7kRg-PTDJWLgcKTGK9z-baUnKeMw@mail.gmail.com> <ef32de1e-d47e-1d0f-3cec-5994c7fdb7ae@mtcc.com> <CAHej_8kjSsQK_XEbdjWzV5npa29YjGadzD06Fmx3QLB4p+n_Cg@mail.gmail.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <d8014c2a-c1c9-9eac-e64a-5f285bab7fd3@tana.it> <CAHej_8mgYr9ERAxmup+keZT5u8L+qgCxcSLH7Z=BEuZLouttpg@mail.gmail.com> <72e20c17-e991-e82a-9120-a27097e3ac58@mtcc.com> <CAHej_8=6huc-N4ymDTOWZXHGjQQ-3RFDdomRzmGp4kOseHckMQ@mail.gmail.com> <7863d250-f56a-1fe1-44ee-fbc7486d48b4@mtcc.com> <CAJ4XoYdMdaE92UOrXvcAqm2iou+PCGg_uzHUsmBsYRe1PivBJw@mail.gmail.com> <ac7b7b32-c544-60f2-1a6a-a5a210ac72ed@mtcc.com> <CAOZAAfNRgxJaO-TJcnvqJTqOCsixzLJVK+vSH-Av+FezY=texw@mail.gmail.com> <0b0c0c7c-f374-6718-5071-b5e9b0d67db3@mtcc.com>
In-Reply-To: <0b0c0c7c-f374-6718-5071-b5e9b0d67db3@mtcc.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Thu, 31 Dec 2020 20:11:34 -0800
Message-ID: <CAL0qLwa-BFpEEYj_HiM5h0O97TpnkpURUKnAOOeb=B5qN1LA5w@mail.gmail.com>
To: Michael Thomas <mike@mtcc.com>
Cc: Seth Blank <seth@valimail.com>, IETF DMARC WG <dmarc@ietf.org>, Dotzero <dotzero@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000005954f305b7cef07a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/1zY9O2YEzNs2dgSrrfSJoJnxbSM>
Subject: Re: [dmarc-ietf] auth-res vs. dmarc
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: Fri, 01 Jan 2021 04:11:50 -0000

On Wed, Dec 30, 2020 at 9:16 AM Michael Thomas <mike@mtcc.com> wrote:

> Later? How much later? Looking at the open tickets it looks you have
> about 5 more years of "later". And I would say the chairs teeing up
> tickets would be a far more efficient means of driving the process than
> shutting down discussions that will become tickets. That other thread on
> privacy should have been closed out weeks ago.
>

The alternative is to have all of those discussions open at the same time.
It's not hard to imagine a way to ensure even less progress than we're
making now.

I believe there are several separate issues:
>
> [...]
>
> 2) Auth-res process-wise is an orphan with no means of discussing it in
> any working group even though it's standards track and has issues
> requiring coordination with this working group
>

I don't understand the basis for this assertion.

There are many standards track documents that are not historic but don't
currently have a working group developing them.  I don't think of them as
orphans.  If the IETF has work to do on one of them, we either spin up a
working group to do the work, or an AD can sponsor the work, or an existing
WG can negotiate to extend its charter to cover the work.

This WG already extended RFC 7601 to become RFC 8601.  It could, in theory,
do so again.

3) The fundamental question that Ned brought up which is whether
> Auth-res is a protocol at all. If it's really just a debugging tool to
> be use by humans, it should definitely just be informational, and
> probably historic. Either Auth-res is useful and supported or not and
> should be killed
>

This is the first time I've heard that it's not useful.  If that were the
case, I wonder why it's gone through four iterations (RFC 5451, then RFC
7001, then RFC 7601, and now RFC 8601).

4) Should DMARC require a normative Authentication-Results Requirements
> section? This process-wise would solve the problem of auth-res in (2)
> and shift the specification of that normative text back to the document
> that is affected by it, letting Auth-res just be a transport vehicle so
> that it doesn't require yet another working group-less update. That is
> what we should have done from the start, but auth-res is an accident of
> history.
>

Section 6.7 of RFC 7489 recommends use of A-R.  If the WG chooses to change
that to a MUST, that seems reasonable to me.

-MSK