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

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 1 Dec 2017 18:09:38 +0000

On Fri, Dec 1, 2017 at 7:38 AM, Murray S. Kucherawy <[email-masked]>
wrote:

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

Where would you like to gather such a consensus? Is this DMARC-WG
sufficient or would you want input from a wider community?

I for one would be in favor of doing a 7601bis to reflect both the shift
from human to machine consumption for the AR as well as these other pieces
of information which are useful for machine analysis.

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 1 Dec 2017 11:32:14 -0800

> sufficient or would you want input from a wider community?

Here's fine.  Or the ART list, or ietf-822.  Or really, anywhere the IETF
considers "on-the-record" in terms of recording consensus.

Let's start here.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Fri, 1 Dec 2017 11:52:55 -0800

On 12/1/2017 11:32 AM, Murray S. Kucherawy wrote:
> On Fri, Dec 1, 2017 at 10:09 AM, Kurt Andersen (b) <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
> Here's fine.  Or the ART list, or ietf-822.  Or really, anywhere the 
> IETF considers "on-the-record" in terms of recording consensus.

There really need to be two different questions.  The easy one is 'where 
should this later assessment be discussed?".  Your answer suffices for 
that, IMO.

The more-difficult question is what the basis of analysis should be?  An 
inherent problem with "in this working group" or the like is just how 
small a sampling of the email industry it is.  It makes it too easy for 
the relatively few participants -- even with the best of intentions -- 
to make highly biases assessments.

So I suggest making a point of soliciting input from various fora, such 
as M3AAWG and the range of *NOG groups.  Anywhere else?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 1 Dec 2017 11:55:56 -0800

On Fri, Dec 1, 2017 at 11:52 AM, Dave Crocker <[email-masked]> wrote:

> inherent problem with "in this working group" or the like is just how small
> a sampling of the email industry it is.  It makes it too easy for the
> relatively few participants -- even with the best of intentions -- to make
> highly biases assessments.
>
> So I suggest making a point of soliciting input from various fora, such as
> M3AAWG and the range of *NOG groups.  Anywhere else?

The ones I mentioned as well, and I would say just mentioning once in all
of those places that the discussion is happening in here is sufficient as a
call for participants.  If nobody else comes, we know we're the only ones
that really care.

-MSK

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 1 Dec 2017 20:46:00 +0000

> call for participants.  If nobody else comes, we know we're the only ones

I have just sent out a call for interest to ietf-smtp, art, and copied this
group. I also sent it to the technical and collaboration lists @ M3AAWG.

--Kurt

---

From: Brandon Long <[email-masked]>
Date: Fri, 01 Dec 2017 22:08:47 +0000

On Fri, Dec 1, 2017 at 10:09 AM Kurt Andersen (b) <[email-masked]> wrote:

>> . . . Or if we really want it in A-R, register it accordingly,
>> independent of ARC.
>>

+1 to 7601bis on those terms.

Brandon

---

From: Brandon Long <[email-masked]>
Date: Fri, 01 Dec 2017 22:10:47 +0000

On Thu, Nov 30, 2017 at 11:38 PM Murray S. Kucherawy <[email-masked]>
wrote:

> On Tue, Sep 5, 2017 at 2:52 PM, Seth Blank <[email-masked]> wrote:
>
>> 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.
>>
>
> Why "client_id" instead of "client-ip"?  (it's an IP address, not some
> opaque identifier)
>

agreed on ip instead of id.

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

agreed on not combining things like this, sure string.split is easy and
all, but let's use the parsing/etc we already have.

Brandon

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.
>
> ===============
>> 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
>>
>
> 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?
>
> 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.
>>
>
> 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.
>
> 4) Have the ptype-properties been defined properly, and will these AAR
>> 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
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Brandon Long <[email-masked]>
Date: Fri, 01 Dec 2017 22:13:52 +0000

And again from the right address, sigh.

Brandon

>> be recorded consensus to back that move.
+1 to 7601bis on Kurt's terms.

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