Message Header Field for Indicating Message Authentication Status
RFC 8601

Note: This ballot was opened for revision 03 and is now closed.

Alexey Melnikov Yes

Ignas Bagdonas No Objection

Deborah Brungard No Objection

(Ben Campbell) (was Discuss) No Objection

Comment (2019-01-22 for -05)
Thank you for resolving my DISCUSS points.

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

Benjamin Kaduk (was Discuss) No Objection

Comment (2019-01-21 for -05)
Thank you for addressing my Discuss points!

Suresh Krishnan No Objection

Warren Kumari No Objection

Comment (2018-11-19 for -04)

Mirja Kühlewind No Objection

(Terry Manderson) No Objection

(Eric Rescorla) No Objection

Comment (2018-11-20 for -04)
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"?

Alvaro Retana No Objection

Comment (2018-11-20 for -04)
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

Adam Roach No Objection

Comment (2018-11-20 for -04)
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.

Martin Vigoureux No Objection