Subject: Re: [dmarc-ietf] ARC draft-08 updates to section 5.1 and WG questions

From: Seth Blank <[email-masked]>
Date: Fri, 6 Oct 2017 16:27:49 -0400

Questions 1, 2, and 4 as they relate to the text I suggested are still open
- and I don't believe the text that was pulled into -09 is correct until
these questions are answered.

On Tue, Sep 5, 2017 at 5:52 PM, Seth Blank <[email-masked]> wrote:

> There have been substantial comments both on and off list about section
> 5.1.1. I've suggested new language for all of 5.1, below, to remove
> normative modification of 7601, and address several other issues. There are
> questions for the WG below the suggested text.
>
> ===============
>
> Replace 5.1 with:
>
> The ARC-Authentication-Results (AAR) header field is semantically and
> syntactically identical to the Authentication-Results header defined in
> [RFC7601#2.2] as authres-header (A-R), except that the first element
> “Authentication-Results:” in authres-header is replaced with
> arc-authres-prefix as follows:
>
>    arc-authres-header-prefix = "ARC-Authentication-Results:" [CFWS]
> arc-info
>
>     arc-info = %x69 “=” arc-hop *([CFWS] “;” [CFWS] propspec) [CFWS] “;”
>
>     arc-hop = 1*2DIGIT  ; 1-50
>
> The purpose of this header field is to transmit the results of any
> authentication done on the message upstream to participating ADMDs
> validating and continuing the chain.
>
> The AAR MUST contain all A-R results from within the participating ADMD,
> regardless of how many A-R headers are on the message.
>
> ===============
>
> Replace 5.1.1 with:
>
> 5.1.1. ptypes and properties for arc-info
>
> Certain information pertinent to ascertaining message disposition can be
> lost in transit when messages are handled by intermediaries. For example,
> failing DKIM signatures are sometimes removed by MTAs, and most DKIM
> signature on messages modified by intermediaries will fail. Therefore, a
> passing DKIM-Signature from the first ARC signer is likely to have been
> removed by final receipt of the message.
>
> The AAR, and in particular the ptype-properties stamped in arc-info,
> provide a mechanism for this information to survive transit.
>
> The ptypes and properties defined in this section SHOULD be stamped in the
> AAR:
>
> * smtp.client_id - The connecting client IP address from which the message
> is received;
> * header.ds - The domain/selector pair for each dkim signature on the
> message (header.ds=example.com,selector)
> * arc.closest_fail - The hop number of the most recent AMS that fails to
> validate, or 0 if all hops pass.
>
> ===============
>
> Open questions:
>
> 1) The optimal ABNF for AAR would inherit the A-R payload ABNF from 7601.
> Unfortunately, authres-header was defined in a way that makes this
> difficult. Is there a better way to say that the AAR inherits the A-R
> payload, and if anything modifies the definition of authres-header in 7601,
> the AAR also needs to inherit this change?
>
> To be super specific, this is the current authres-header ABNF from 7601:
>
>      authres-header = "Authentication-Results:" [CFWS] authserv-id
>               [ CFWS authres-version ]
>               ( no-result / 1*resinfo ) [CFWS] CRLF
>
> Optimally, there would be:
>
>      authres-payload = [CFWS] authserv-id
>               [ CFWS authres-version ]
>               ( no-result / 1*resinfo ) [CFWS] CRLF
>
> And then we could have:
>
>    arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info
> authres-payload
>
> 2) The optimal way to transmit DKIM selector information is in the DKIM
> A-R methodspec as header.s. If we want to prevent a normative modification
> of 7601, I've proposed "header.ds" which will accomplish the same thing.
>
> 3) In the ARC-Seal megathread, there was an aside about knowing the last
> hop which validated:
>
> On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana <[email-masked]>
> wrote:
> > That seems like it would be enough to fix that objection.  An additional
> "first AMS failure" header at each hop would give you a list of who
> actually modified the message.
>
> arc.closest_fail has been defined to accomplish this.
>
> 4) Have the ptype-properties been defined properly, and will these AAR
> ptype-properties need an IANA registry?
>
> 5) Finally, the ams[n] and as[n] entities were dropped, as these values
> are guaranteed to be on the final message if an ARC chain passes, so
> there's no need to encode them separately.
>
> Seth
>