Message Header Field for Indicating Message Authentication Status
draft-ietf-dmarc-rfc7601bis-06

[Ballot discuss]
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
more.]

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.

[Ballot comment]
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
reading.

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
  report.

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.

[Ballot comment]

Thanks to everyone for the work that went into this revision.

I agree with Ben's DISCUSS. In particular, I'm concerned by the text in §6.4,
which indicates that the IANA registry will continue to point at RFC 7410 while
the actual *meaning* of those values will mean something different than RFC 7410
defines. At a minimum, I think this document needs to add itself to the IANA
table for those entries.

But I think the cleanest approach -- and the one that is most consistent with
the predecessor documents to this one -- is to copy the IANA entries forward
with an indication that the values are already registered, but should be updated
to point to this document.

---------------------------------------------------------------------------

RFC 7208 is referred to by both [SPF] and [RFC7208], while only appearing as
[SPF] in the references section. Consider rationalizing this.

I recognize that the title was copied directly from RFC 7601, but please
consider revising it to indicate that this document pertains to email.

---------------------------------------------------------------------------

§1.5.1:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in [KEYWORDS].

Please consider updating to match the boilerplate in RFC 8174.

---------------------------------------------------------------------------

I have otherwise reviewed the diffs from RFC 7601, and find nothing to comment
on. I echo Ben's comments thanking you for making limited changes to the
document.

[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D5317



IMPORTANT
S 7.10.
>      processing of these is outside of the intended scope of this document
>      (see Section 1.3), some early guidance to MUA developers is
>      appropriate here.
> 
>      Since MTAs are unlikely to strip Authentication-Results header fields
>      after mailbox delivery, MUAs are advised in Section 4.1 to ignore

I think you want to be stronger than "are advised to"

COMMENTS
S 1.1.
>      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.

And also a trustworthy path from the validating MTA


S 1.2.
>      Thus, this document defines a "trust boundary" as the delineation
>      between "external" and "internal" entities.  Services that are
>      internal -- within the trust boundary -- are provided by the ADMD's
>      infrastructure for its users.  Those that are external are outside of
>      the authority of the ADMD.  By this definition, hosts that are within
>      a trust boundary are subject to the ADMD's authority and policies,

This seems like a reasonable design, but not the only one. For
instance, Gmail might attach these headers, but I don't think of my
MUA as being subject to its authority and policies.


S 1.5.1.
> 
>  1.5.1.  Key Words
> 
>      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>      document are to be interpreted as described in [KEYWORDS].

I'm probably the 10th person to suggest 8174 boilerplate.


S 1.5.3.
>      agents, assign (some) responsibility for the message (which implies
>      authorization), and ensure that the listed portions of the message
>      were not modified in transit.  Since the signatures are not tied to
>      SMTP connections, they can be added by either the ADMD of origin,
>      intermediate ADMDs (such as a mailing list server), other handling
>      agents, or any combination.

I'm not sure how persuaded I am by this terminology. However,
regardless of that, this claim about SPF seems problematic in the
sense that you could have an intermediate MTA decorate the message
with the incoming IP address (in some unspecified way)  but then have
the terminal MTA do the SPF validation.


S 2.2.
>      combination of these can be applied.
> 
>  2.2.  Formal Definition
> 
>      Formally, the header field is specified as follows using Augmented
>      Backus-Naur Form ([ABNF]):

An example would be kind of helpful here.


S 2.4.
> 
>      This ptype existed in the original specification for this header
>      field, but without a complete description or example of intended use.
>      As a result, it has not seen any practical use to date that matches
>      its intended purpose.  These added details are provided to guide
>      implementers toward proper use.

This text is odd in a bis draft, because "the original" is not 7601 or
7001.


S 5.
>      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.  This could mean
>      each MTA will have to be equipped with a list of internal MTAs known
>      to be compliant (and hence trustworthy).

It's not "known to be compliant" but rather "known to be trusted by
any MUA within the trust boundary"


S 5.
>      version (express or implied) that it does not support.  However, an
>      MTA MUST remove such a header field if the [SMTP] connection relaying
>      the message is not from a trusted internal MTA.  This means the MTA
>      needs to be able to understand versions of this header field at least
>      as late as the ones understood by the MUAs or other consumers within
>      its ADMD.

Doesn't this have the impact of breaking signatures as you just said
above?


S 7.1.
>  7.1.  Forged Header Fields
> 
>      An MUA or filter that accesses a mailbox whose messages are handled
>      by a non-conformant MTA, and understands Authentication-Results
>      header fields, could potentially make false conclusions based on
>      forged header fields.  A malicious user or agent could forge a header

I think the text here you want is that the MUA understands these
fields, not the non-conformant MTA. So perhaps you can rewrite this?


S 8.2.
> 
>      A message that was delivered by an MTA that conforms to this
>      specification and applied some message authentication:
> 
>          Authentication-Results: example.com;
>                    spf=pass smtp.mailfrom=example.net

Maybe this example would be good to put up front?


S 8.2.
>          to know how to do the work that upstream MTAs do; they only need
>          the results of that work.
> 
>      4.  Evaluations about the quality of a message, from simple token
>          matching (e.g., a list of preferred DNS domains) to cryptanalysis
>          (e.g., public/private key work), do have a cost and thus need to

This is not usually what we would call "cryptanalysis". Perhaps you
mean "cryptographic verification"?

[Ballot discuss]
This is mainly a process discuss. I share Alvaro's concern about this being marked as "updating" RFC7601, when it seem like a full replacement. I'm promoting it to a DISCUSS because I think this needs to be resolved before publication.

The current structure will make it very difficult for readers to figure out which parts of each doc they need to worry about. I think it needs to either go back to "obsoleting" 7601, or it needs to be recast to just talk about the changes. Note that if the former path is chosen, the IANA considerations in 7601 will need to be copied forward.

[Ballot comment]
I mostly just reviewed the diff. Thank you for mostly avoiding unnecessary changes. That makes the diff tools much more useful than they are for bis drafts that make wholesale organization and stylistic changes.

[Ballot comment]
I don't understand why this document is tagged as an Update to RFC7601 and not as Obsoleting it.  This change was made between the -03 (which was the one in the IETF LC) and the -04 (current) versions.

As far as I can tell, the contents of this document are the same as rfc7601, + 2 new headers.  Just as the reference for the Authentication-Results Header Field is being updated to point at this document, the registry pointers to rfc7601 can also be moved.

I note that this point was brought up during both the AD Review [1] and the IETF LC [2], which is why I'm not balloting DISCUSS.  However, I think that the solution (Updating instead of Obsoleting) is not the correct one.

[1] https://mailarchive.ietf.org/arch/msg/dmarc/ug2XvXqGjyd6S7utkrSq7pq3wv0
[2] https://mailarchive.ietf.org/arch/msg/ietf/L28CWVReXoBBiSSy2tc-JPeXD3I

[Ballot comment]
I don't understand why this document is tagged as an Update to RFC7601 and not as Obsoleting it.  This change was made between the -03 (which was the one in the IETF LC) and the -04 (current) versions.

As far as I can tell, the contents of this document are the same as rfc7601, + 2 new headers.  Just as the reference for the Authentication-Results Header Field is being updated to point at this document, the registry pointers to rfc7601 can be moved as well.

I note that this point was brought up during both the AD Review [1] and the IETF LC [2], which is why I'm not balloting DISCUSS.  However, I think that the solution (Updating instead of Obsoleting) is the correct one.

[1] https://mailarchive.ietf.org/arch/msg/dmarc/ug2XvXqGjyd6S7utkrSq7pq3wv0
[2] https://mailarchive.ietf.org/arch/msg/ietf/L28CWVReXoBBiSSy2tc-JPeXD3I

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dmarc-rfc7601bis-03. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, regarding Section 6.1 of the current draft, IANA confirms that Authentication-Results header is in the Permanent Message Header Field Names registry on the Message Headers registry page located at:

https://www.iana.org/assignments/message-headers/

IANA Question --> should the reference be changed to [ RFC-to-be ] or should [ RFC-to-be ] be added to the existing reference already in place?

Second, in the Email Authentication Methods registry on the Email Authentication Parameters registry page located at:

https://www.iana.org/assignments/email-auth/

two new, methods are to be registered as follows:

Method: dkim
Definition: [ RFC-to-be ]
ptype: header
Property: a
Value: value of signature "a" tag
Status: active
Version: a

Method: dkim
Definition: [ RFC-to-be ]
ptype: header
Property: s
Value: value of signature "s" tag
Status: active
Version: 1

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, regarding section 6.4 of the current draft should the Email Authentication Property Types registry on the Email Authentication Parameters registry page located at:

https://www.iana.org/assignments/email-auth/

have its reference changed from [RFC7601] to [ RFC-to-be ]?

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-11-08):

From: The IESG
To: IETF-Announce
CC: draft-ietf-dmarc-rfc7601bis@ietf.org, Tim Draegen , dmarc@ietf.org, alexey.melnikov@isode.com, tim@dmarcian.com, dmarc-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Message Header Field for Indicating Message Authentication Status) to Proposed Standard


The IESG has received a request from the Domain-based Message Authentication,
Reporting & Conformance WG (dmarc) to consider the following document: -
'Message Header Field for Indicating Message Authentication Status'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-11-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document specifies a message header field called Authentication-
  Results for use with electronic mail messages to indicate the results
  of message authentication efforts.  Any receiver-side software, such
  as mail filters or Mail User Agents (MUAs), can use this header field
  to relay that information in a convenient and meaningful way to users
  or to make sorting and filtering decisions.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary
The Document Shepherd for this document is Tim Draegen. The responsible Area Director is Alexey Melnikov.

This document is an update of RFC 7601. The document specifies a message header field called Authentication-Results for use with electronic mail messages to indicate the results of message authentication efforts. Changes to the prior specification are made to note support for EAI (internationalized email addresses), refine the ABNF definition to allow for easier citing by external documents (no change in semantics, just a split of an existing term), clarify minor editorial nuances, and to update the "Email Authentication Methods" Registry to allow for communication of DKIM-related information (algorithm and selector).

7601 is a Standards Track document. This update does not change the intended status.

2. Review and Consensus
There is strong consensus for this document in the DMARC WG. The WG set out to update 7601 with only minimal changes needed to bring the document current with existing practice (EAI), ongoing refinement of existing specification (DKIM), and change needed to simplify ongoing WG development (ABNF changes). Editorial changes are only picked up to correct errors and grammar nits. There was some appetite to include additional editorial and content changes, but the WG's scope required changes to be obvious and non-controversial.

3. Intellectual Property
The author has confirmed conformance with BCPs 78 and 79. Seeing as how this is a minor update to an existing document, this is not a surprise.

4. Other Points
No downward references are added. Several previously Informative references are moved to the Normative reference section to reflect the evolution of the specification. Additional Normative references are added due to including support for EAI.

No new IANA registries are created. Two new entries to the "Email Authentication Methods" registry are made, both related to communication of DKIM information using the Authentication-Results email header field. The new entries have already been reviewed and approvied by the designated registry Experts.