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

Benjamin Kaduk <kaduk@mit.edu> Wed, 21 November 2018 13:58 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: dmarc@ietf.org
Delivered-To: dmarc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A936B126CB6; Wed, 21 Nov 2018 05:58:37 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-dmarc-rfc7601bis@ietf.org, Tim Draegen <tim@dmarcian.com>, dmarc-chairs@ietf.org, tim@dmarcian.com, dmarc@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154280871768.11502.10059395575461348698.idtracker@ietfa.amsl.com>
Date: Wed, 21 Nov 2018 05:58:37 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/DxJh5Bf7d9NRSZ0o84EwhZFhKIo>
Subject: [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
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: Wed, 21 Nov 2018 13:58:38 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dmarc-rfc7601bis-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


I also appreciate the efforts to reduce the diff between RFC 7601 and
this document; it does help readability greatly.  (I also support Ben's
Discuss.)  Unfortunately, it also can obscure some aspects where the
text of the document did need to change as part of the update, but has
not done so.

For example, in Section 1:

   There exist registries for tokens used within this header field that
   refer to the specifications listed above.  Section 6 describes the
   registries and their contents and specifies the process by which

I don't think all of this is still present anymore.  (If we were talking
about registration policies, for example, we'd need an 8126 reference to
replace the 5226 reference that was removed.)

   entries are added or updated.  It also updates the existing contents
   to match the current states of these specifications.

[We should double-check that everything that now allows EAI-formatted
stuff is updated to also refer to this document from the IANA registry.
On first glance this might include vbr.mv and vbr.md, but probably much

Don't we need to mention the updates (or obsoletes) relationship w.r.t.
7601 in the Abstract and Introduction?

Section 4.1 has:

   MUAs and downstream filters MUST ignore any result reported using a
   "result" not specified in the IANA "Result Code" registry or a
   "ptype" not listed in the "Email Authentication Property Types"
   registry for such values as defined in Section 6.  [...]

This would seem to be an internal inconsistency, in that it seems to
preclude any sort of experimental usage as described in Sections 2.7.x.

In Section 2.3:

   Combinations of ptypes and properties are registered and described in
   the "Email Authentication Methods" registry, coupled with the
   authentication methods with which they are used.  This is further
   described in Section 6.

The relevant subsection of section 6 is a pretty empty stub now.


Thanks you for updating in response to the secdir review!

Are we now intending to restrict ourselvesto domain-based authentication
schemes, having removed the disclaimer present in 7601 about the intent
of the document?

Section 1.1

   In particular, the mere presence of this header field does not mean
   its contents are valid.  Rather, the header field is reporting
   assertions made by one or more authentication schemes applied
   somewhere upstream.  For an MUA or downstream filter to treat the
   assertions as actually valid, there must be an assessment of the
   trust relationship among such agents, the validating MTA, and the
   mechanism for conveying the information

If this document is reporting assertions made upstream, we should say
what kind of integrity and authenticity guarantees we do or do not
provide for the reported information.  (That is, "this header is
transmitted in cleartext and could be modified by any agent along the
delivery path", modulo the speculation we have later about potential
ways to improve on that situation.)  Section 1.6 goes a bit farther in
this vein; maybe a forward reference is in order?

Section 1.4

Isn't there a requirement to drop this header on the boundary, if there
are any internal consumers?  This is not a global requiremnet on
existing servers, of course, but a deployment consideration that may
affect existing servers.  The end of section 7.1 seems to cover this
situation pretty well, as well.

Section 1.5.1

Please consider using the RFC 8174 version of the BCP 14 boilerplate.

Section 1.5.4

   o  An "intermediate MTA" is any MTA that is not a delivery MTA and is
      also not the first MTA to handle the message.

Is this intended to be global or within an ADMD?

Section 2.2

I guess wouldn't be a whole lot of value in subtyping Keyword to have
one symbol per registry, though the thought did occur to me while

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.  (Do we need to make it more clear that the
"property" is defined within the context of the method?)

   The results for Sender ID are listed and described in Section 4.2 of
   [SENDERID], but for the purposes of this specification, the SPF
   definitions enumerated above are used instead.  Also, [SENDERID]
   specifies result codes that use mixed case, but they are typically
   used all lowercase in this context.

We use much stronger statements about lowercasing than "typically",
elsewhere in this doc.  Is this time different?

Section 2.7.6

   Experimental method identifiers MUST only be used within ADMDs that
   have explicitly consented to use them.  These method identifiers and
   the parameters associated with them are not documented in RFCs.
   Therefore, they are subject to change at any time and not suitable
   for production use.  [...]

This part seems to value RFC status too highly -- earlier in the section
we only say that they should "preferably" be published in an RFC.

Section 2.7.7

Do we want to say that temporary registrations are available for
wide-scale or long-running experiments?

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

Does that in practice constrain "iprev" usage to within a single ADMD?

Section 4.1

   MUAs SHOULD ignore instances of this header field discovered within
   message/rfc822 MIME attachments.

When would I want to not ignore it?

Section 5

I guess there's not really any special behavior to worry about when a
message's path causes it to have two or more disjoint path segments in
its delivery path that go through a given ADMD.  (That is, delete on
entry is still the right thing to do.)  The last paragraph of Section
1.2 covers a related case, but I am thinking of something like a message
that gets delivered to an expander and some of the recipients' delivery
path would then return through a previously visited domain.

                                                For example, an MTA for
   example.com receiving a message MUST delete or otherwise obscure any
   instance of this header field bearing an authentication service
   identifier indicating that the header field was added within
   example.com prior to adding its own header fields.  [...]

Do we want to say anything about the authserv-id here?

Section 6.4

I think we need to update the registry to also refer to this document.

Appendix C

   2.  Border MTAs are more likely to have direct access to external
       sources of authentication or reputation information since modern
       MUAs are more likely to be heavily firewalled.  [...]

It's unclear that this statement about "modern MUAs" is still true,
given the "zero trust" movement and such.