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

From: Seth Blank <[email-masked]>
Date: Thu, 23 Nov 2017 05:39:37 +0000

Bumping this, too. All items below are still open.

On Fri, Oct 6, 2017 at 8:27 PM, Seth Blank <[email-masked]> wrote:

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

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 29 Nov 2017 17:12:47 +0000

On Thu, Nov 23, 2017 at 5:39 AM, Seth Blank <[email-masked]> wrote:

>>> <elided>
>>> 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
Has there been any traction on the idea of modifying 7601 to implement this
partitioning (bis)? Or should we bake in our own "hotwire" of the existing
spec?

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 30 Nov 2017 23:38:48 -0800

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

> 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;

Why "client_id" instead of "client-ip"?  (it's an IP address, not some
opaque identifier)

Why "header.ds" and not "header.d" and "header.s"?  (why combine them?)

Why "arc.closest_fail" and not "arc.closest-fail"?  (use a hyphen, to be
consistent with other entries already in the registry)

Unless someone wants to point me at the part of the spec that says
otherwise, the IP address is utterly orthogonal to anything ARC is doing.
I'd rather not shoe-horn it in here, even if DMARC operators might want
it.  Rather, we should do a separate document (outside this WG if needed)
that registers a header field for this, since there's been something like
X-Original-IP in public use for years anyway, and then just require that it
be signed or something.  Or if we really want it in A-R, register it
accordingly, independent of ARC.

But if we want to do that last thing, I'd like to have some sort of
discussion on the record for changing the scope of A-R, which is really
what we're talking about here.  As I've said before, A-R's original purpose
was to collect data about authentication work done at the ingress MTA that
might be of interest to users or filters.  We've specifically kept things
like IP addresses unregistered on the basis that your average human won't
know whether to trust one string of octets over another, and there's a
treatise in the appendix of RFC7601 and all of its predecessors that lays
out why.  But that's the logic we applied eight years ago when RFC5451 was
written.  If in the intervening time we've decided we want to repurpose it
to carry arbitrary stuff that might be of benefit to filters and concede
that users aren't the likely primary consumers as we intended, then we
should probably do up an RFC7601bis that says so, and renovate the prose
and registries accordingly.  I'll put the editing work in, but there has to
be recorded consensus to back that move.

===============
>    arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info

That seems reasonable to me.

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

Why the merge?

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

I'm not sure I like a hop number in here, which harkens back to Received
counts.  I'd rather say it's an instance number, or better yet the sealing
domain name.

> ptype-properties need an IANA registry?

If we decide we want AAR separate from of AR, then we also need to decide
if AAR uses the AR registry (in which case all of this has to get mushed in
with regular A-R stuff, but flagged "ARC use only" or something (ick), or
we'll need our own registry (ugh).

-MSK