Re: [dmarc-ietf] Benjamin Kaduk's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT)

"Murray S. Kucherawy" <superuser@gmail.com> Mon, 21 January 2019 07:26 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 CC3DB130F65; Sun, 20 Jan 2019 23:26:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 vYXGPJMmekkO; Sun, 20 Jan 2019 23:26:00 -0800 (PST)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 035B1130F5B; Sun, 20 Jan 2019 23:26:00 -0800 (PST)
Received: by mail-lj1-x234.google.com with SMTP id q2-v6so16595580lji.10; Sun, 20 Jan 2019 23:25:59 -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=J3MsZcCM58gXtTFxoo56lwgZGsKANZmPDeerDDKF0OY=; b=Kii20hkIAnMB8/fFF8wom47xlfS5oDVxn66EtZvGyx+WdVmdzvapmFNvZcVKUytZ+A XEa+NZFyajipS6tNDqJ2Dj9B/ipynz9yZ7eXcVL6qfcp2z50phaBmt6XegER2wNBR93h y2rQWe6XmRvhHClAH2UZTiGgOwUsfMhbe6GhNCf7ilSU+zbq1MP2tM4K6vtTaQ8Yva4W PSQUvmcoMmePidcYVD9KCL1JMR6zAgmIuDfGnLLFc/Krzcxv+DR4LVyRL/FfgvhPbuYs uRwDh7gLiss93sxMHXq+R6CjCSsiGJE+GsAKh526DdIOZLoqASEHHMA6KdOtS5YvMJVN WWOw==
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=J3MsZcCM58gXtTFxoo56lwgZGsKANZmPDeerDDKF0OY=; b=php8c8APYj4TWes1nNOjKup2HmSZS0VQt4OD/co5+hIjfsZFkchoLyqT5RzbUqRQfM vJVrOEAk2UcG/DKbCwbE5Xf0ux+kojp3aicI+rpPPpRhGEUOok8LVKO4+ndYnNnAh9ne 6I953HGrmxOMaHQDyyICReiqN1Z8nqOf5zPO0+oKmVjvj2XPBKRgJdf80AxxGkoZ01jf BvccuvGJMl0OkIC3kdvrAPrbVMt4kSrC3fEauIV7F9ke13jPglmIKuZOPper1kvEsgG9 r4HPnntrqUK+DtjIxfU0eEIDSD+c4rtWXahfbl07VsIRIokEkxgVjbpDT2a73nTe9/w4 usWg==
X-Gm-Message-State: AJcUukdw7ZTOHR7yv+zh69bBL4EAB5Na/apiojoTB6FbKh7xcankr7BO A4/y9j5dj8nteUr/gpC4RrhUhwEDKtt2mOa89D1Pig==
X-Google-Smtp-Source: ALg8bN7lceXGtY2KF0psXgIbJQidmxLq9YzpCA4NMDgrGtKGzKlNsholSqCqNrE7iG47FdJIpUinGnsZeCXECIdlQpA=
X-Received: by 2002:a2e:750a:: with SMTP id q10-v6mr19074824ljc.39.1548055558091; Sun, 20 Jan 2019 23:25:58 -0800 (PST)
MIME-Version: 1.0
References: <154280871768.11502.10059395575461348698.idtracker@ietfa.amsl.com> <CAL0qLwZb_=N+nEQQqvqURKvz9yM1bMZfyhrXcqVf0rm90qpcsQ@mail.gmail.com> <20190106172729.GL28515@kduck.kaduk.org>
In-Reply-To: <20190106172729.GL28515@kduck.kaduk.org>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Mon, 21 Jan 2019 02:25:45 -0500
Message-ID: <CAL0qLwbmcEVgVcJTBU26gmVGaWV4Gy0fYArY80ZcDYf=wF-UKg@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, Tim Draegen <tim@dmarcian.com>, IETF DMARC WG <dmarc@ietf.org>, draft-ietf-dmarc-rfc7601bis@ietf.org, dmarc-chairs@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a1f762057ff2c51f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/209Uw3qnRzpfO208A6xH-QDYtXw>
Subject: Re: [dmarc-ietf] Benjamin Kaduk's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT)
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: Mon, 21 Jan 2019 07:26:02 -0000

On Sun, Jan 6, 2019 at 12:27 PM Benjamin Kaduk <kaduk@mit.edu> wrote:

> > Section 2.3
> > >
> > >    body:  Information that was extracted from the body of the message.
> > > [...]
> > >       interest.  The "property" is an indication of where within the
> > >       message body the extracted content was found, and can indicate an
> > >       offset, identify a MIME part, etc.
> > >
> > > I'm not seeing where it's specified how the "property" gives an offset.
> > > I see other descriptions below about specific header fields and SMTP
> > > verbs and such, though.
> >
> >
> > That's text from the 2009 version of this work.  Those were speculative
> at
> > the time and haven't yet materialized, at least not in standardized use.
>
> Are you proposing to leave the text unchanged regardless?
>

I know the use case exists, because I wrote that text when I worked for a
company that was likely to make use of it, but it appears that hasn't
happened in the deployed universe.  So now we have a registry entry for the
"body" ptype which isn't deprecated, but possibly no live uses of it.  The
working group didn't discuss taking any action to either "fix" or bolster
this, as its focus was elsewhere (specifically the changes needed to
support the DMARC/ARC work).

I'm inclined to leave it as-is, possibly with a remark capturing what I
just said here.  If no uses of it appear before someone decides to revise
this again, we can formally deprecate it.

> Section 3
> > >
> > >    of the validity of the connection's identity using DNS.  It is
> > >    incumbent upon an agent making use of the reported "iprev" result to
> > >    understand what exactly that particular verifier is attempting to
> > >    report.
> > >
> > > Does that in practice constrain "iprev" usage to within a single ADMD?
> > >
> >
> > I would imagine so.
>
> This is just the COMMENT section, so do what you will, but I would consider
> mentioning this property of "iprev" more explicitly.
>

Actually, on second thought, it doesn't: ADMD #1 could attach an "iprev"
result that ADMD #2 could decide it trusts.  That is, sort of, the ARC
model -- you decide whose external results you're going to believe.

About to post the new version.

-MSK