Subject: Re: [dmarc-ietf] selectors in AAR.

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 5 Jul 2017 15:33:22 -0700

On Fri, Jun 23, 2017 at 3:17 PM, Brandon Long <[email-masked]> wrote:

> On Wed, May 31, 2017 at 10:07 PM, Murray S. Kucherawy <[email-masked]
> > wrote:
>
>> On Thu, May 4, 2017 at 4:19 PM, Peter Goldstein <[email-masked]>
>> wrote:
>>
>>> So as a consumer of these reports I'd definitely like to see a
>>> structured value with as much information as possible.
>>>
>>
> [snip]
>
>>
>>>    - DKIM Selectors - Unfortunately we probably can't get the DKIM
>>>    signature selectors (because they aren't generally recorded in the
>>>    Authentication-Results, and so won't be available to downstream hops), but
>>>    if we can get them, that would be very helpful.
>>>
>>>
>> They could be added to A-R, in theory, but they're not really
>> user-consumable which is why they were originally omitted.
>>
>
> Thinking some more on this while thinking about the format of the DMARC
> report, I think we should consider it.
>
> The AuthRes header was meant to help pass information to the end user (or
> their mail client) from their own mail system.
>
> The AAR header is meant to pass information from each hop to all of the
> following hops, and meant mostly (at this point) to inform the DMARC
> handling of the message.
>
> And part of the point of DMARC is informing admins/domain owners on how
> their mail is being evaluated to help them get to stricter levels.
> [...]
>

The original intent of selectors and domain names, going back to
DomainKeys, was that selectors would be used to identify a key, and the
domain name would be used to identify the source, or responsible party,
regarding a message.  Selectors can be rotated in and out of service for a
given domain name without changing the domain name.  Reputation, therefore,
would be developed about the domain name (the "d=") specifically.
Selectors were orthongonal.

Based on discussions with Seth and Gene earlier, it sounds like the
industry has sadly not taken up the habit of key and selector rotation, and
instead the pairing of "s=" and "d=" now identifies a single source.
Ignoring the obvious security problem this introduces, we're now talking
about implicitly formalizing this tuple as identifying a source.  This
contradicts that original intent.  In particular, if one were to develop
reputation in this way, then a key being rotated out takes the reputation
with it; signers would have to establish some procedure for doing so with
substantial overlap so that the new key can be "warmed".  Worse, in an
emergency where a key is compromised, that tuple's reputation irretrievably
suffers.

How is this better than encouraging the industry to adopt the separation of
functions that was originally intended?

-MSK

---

From: Seth Blank <[email-masked]>
Date: Wed, 5 Jul 2017 16:36:14 -0700

On Wed, Jul 5, 2017 at 3:33 PM, Murray S. Kucherawy <[email-masked]>
wrote:

>> On Wed, May 31, 2017 at 10:07 PM, Murray S. Kucherawy <
>> [email-masked]> wrote:
>>
> How is this better than encouraging the industry to adopt the separation
> of functions that was originally intended?
>

The *only* intent here is to report back services that break authentication
to the domain owner in a DMARC report. As such, the selector disambiguates
services (especially when there are multiple hops, some of which might have
the same d=) and allows a reporter to make a clear determination to a
report consumer of where authentication failed so that a service can be
properly configured in SPF or with DKIM.

In many cases, this process is ambiguous or impossible without the
inclusion of selectors. This adds demonstrable value for a consumer of
DMARC reports where mail is indirectly delivered.

This solves a real problem now, and has nothing to do with reputation which
would be silly to build on top of this tuple for the reasons you've
outlined.

Seth

>
> -MSK
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 5 Jul 2017 22:42:06 -0700

On Wed, Jul 5, 2017 at 4:36 PM, Seth Blank <[email-masked]> wrote:

> The *only* intent here is to report back services that break
> authentication to the domain owner in a DMARC report. As such, the selector
> disambiguates services (especially when there are multiple hops, some of
> which might have the same d=) and allows a reporter to make a clear
> determination to a report consumer of where authentication failed so that a
> service can be properly configured in SPF or with DKIM.
>

Are we talking about adding this to the DMARC reports or to A-R?  Both have
been suggested in this thread.

I believe you're specifically talking about DMARC reports, and I have less
of a concern with those.  On the other hand, adding them to A-R makes less
sense because that's got users partly in mind, and I don't think a user
would care too much what selector is being used in a DKIM signature.
Explicitly discouraging development of reputation based on an s=/d= pairing
would be an added bonus.

-MSK

---

From: Seth Blank <[email-masked]>
Date: Thu, 6 Jul 2017 10:19:50 -0700

On Wed, Jul 5, 2017 at 10:42 PM, Murray S. Kucherawy <[email-masked]>
wrote:

> Are we talking about adding this to the DMARC reports or to A-R?  Both
> have been suggested in this thread.
>

I think the reputation conversation here is a red herring. Anyone making a
reputation decision (i.e. receivers) would be in receipt of the actual
message, with the DKIM-Signature blocks and all other headers, and can use
whatever data they want, including far more than a d,s pairing, to make a
reputation judgement.

This thread is only about encapsulating information useful for a consumer
of DMARC reports, as that consumer will not have the message and its
headers. Selectors are critical here for tying things together.

The DMARC report data is generated from the AAR, because the AAR transports
the relevant data (the receiver only has data on the last hop without the
AAR) in a signed manner that survives manipulations to the chain. Data gets
into the AAR by first being stamped in the A-R and then getting
encapsulated when the ARC Set is Sealed.

So putting selectors in the A-R accomplishes transmitting selectors for use
in a DMARC report cleanly; only a ptype needs to be registered, and no
changes to the spec or AAR construction are needed.

It was floated a while back on the list of putting this information in only
the AAR and not the A-R directly, but that was shot down because the
consensus was the AAR should only transit information that had been stamped
in an A-R, and not additional data. I'm happy to revisit this, I think
selectors and source ip make more sense in the AAR than the A-R (and then
we don't need new ptypes or additional headers for transmission), but I
thought I'd already lost that battle ;-)

Seth

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 6 Jul 2017 18:05:32 -0700

On Thu, Jul 6, 2017 at 10:19 AM, Seth Blank <[email-masked]> wrote:

> The DMARC report data is generated from the AAR, because the AAR
> transports the relevant data (the receiver only has data on the last hop
> without the AAR) in a signed manner that survives manipulations to the
> chain. Data gets into the AAR by first being stamped in the A-R and then
> getting encapsulated when the ARC Set is Sealed.
>
> So putting selectors in the A-R accomplishes transmitting selectors for
> use in a DMARC report cleanly; only a ptype needs to be registered, and no

I think this presupposes that there's some connective tissue between, but
distinct from, the DMARC report generator and the ARC implementation.  Do
we have to presume that, or is it enough to make space for it in the DMARC
report, and then not specify how that information goes from one component
to the next?  Then an operator can decide how to move that information
between those two components however it sees fit, and there's no need to
rub up against A-R's intended use (which I would argue doesn't include
relaying selectors downstream).

-MSK

---

From: Seth Blank <[email-masked]>
Date: Thu, 6 Jul 2017 18:25:29 -0700

> relaying selectors downstream).

So this is a very fair comment. But I think it's deeply problematic.

In the case of a direct mail flow, the receiver has all the needed
information from the SMTP connection and A-R payload to create a report.
None of this information is present once a message arrives at a receiver in
an indirect manner.

I would strenuously argue the charter's call for "eliminating the DMARC's
effects on indirect mail flows" requires that reporting - which is the
fundamental feedback mechanism for a sender - work properly under said
fixes. This is impossible for a receiver to do without ARC passing the
information along. And ARC has this transmission mechanism in its AAR, but
we need to make sure the appropriate information is in it.

---

From: Tim Draegen <[email-masked]>
Date: Fri, 7 Jul 2017 09:12:37 -0400

> On Jul 5, 2017, at 6:33 PM, Murray S. Kucherawy <[email-masked]> wrote:
> 
> Based on discussions with Seth and Gene earlier, it sounds like the industry has sadly not taken up the habit of key and selector rotation, and instead the pairing of "s=" and "d=" now identifies a single source.  Ignoring the obvious security problem this introduces, we're now talking about implicitly formalizing this tuple as identifying a source.  This contradicts that original intent.  In particular, if one were to develop reputation in this way, then a key being rotated out takes the reputation with it; signers would have to establish some procedure for doing so with substantial overlap so that the new key can be "warmed".  Worse, in an emergency where a key is compromised, that tuple's reputation irretrievably suffers.
> 
> How is this better than encouraging the industry to adopt the separation of functions that was originally intended?

I just caught up on the "selectors in AAR" thread, but wanted to go back to this early statement about key rotation and pairing of "s=" and "d=" to identify a single source. Thus a new Subject: is born.

It's true key rotation is rare. People are figuring out how to do it, though. Due to the size and scope of email's installed base, it takes a really long time for the knowledge to slosh around the Internet. Using multiple CNAMEs, delegating sub-domains, even out-sourcing all things _domainkey.* is possible. Unfortunately there isn't good guidance on the pros and cons of each way, and so people implement quick and dirty 'cause they don't know any better.

Using selectors to identify a single source of email isn't right, IMO. Given the way things play out, once people are told that selectors are important because they're used to identify sources of email (doesn't even matter how true it is), then we'll be stuck with selectors being a component of reputation. People will make do with what they've got.

If nature abhors a vacuum, the missing piece is "what identifies a source?". Selectors might fill that hole unless real guidance is provided.

Using sub-domains to differentiate services works nicely. Today lack of clear guidance means a Domain Owner has to deal with a mashup of different ways to integrate with 3rd party senders. 3rd party senders make do with what they've got, and that is often very constrained.

Maybe such guidance should go into the "Usage Guide". Declaring which parts of the DMARC puzzle should be used to build reputation system seems pretty important if interoperability is the goal.

-= Tim

---

From: Tim Draegen <[email-masked]>
Date: Fri, 7 Jul 2017 09:40:34 -0400

> On Jul 6, 2017, at 9:25 PM, Seth Blank <[email-masked]> wrote:
> 
> In the case of a direct mail flow, the receiver has all the needed information from the SMTP connection and A-R payload to create a report. None of this information is present once a message arrives at a receiver in an indirect manner.
> 
> I would strenuously argue the charter's call for "eliminating the DMARC's effects on indirect mail flows" requires that reporting - which is the fundamental feedback mechanism for a sender - work properly under said fixes. This is impossible for a receiver to do without ARC passing the information along. And ARC has this transmission mechanism in its AAR, but we need to make sure the appropriate information is in it.

It might be useful to show what the desired DMARC reporting looks like for email flows where ARC is at play.

For example, maybe "override" just shows "arc_at_work" with existing fields identifying the last hop (like is done today). In that case reporting works properly.

If there's a more robust presentation that is wanted, it would help the list to see an example. Maybe then people could follow along to see why the inclusion of selectors is necessary from a DMARC reporting perspective.

=- Tim

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 07 Jul 2017 10:11:36 -0400

On Friday, July 07, 2017 09:12:37 AM Tim Draegen wrote:
> > industry has sadly not taken up the habit of key and selector rotation,
> > and instead the pairing of "s=" and "d=" now identifies a single source. 
> > emergency where a key is compromised, that tuple's reputation
> > irretrievably suffers.
> > 
> I just caught up on the "selectors in AAR" thread, but wanted to go back to
> this early statement about key rotation and pairing of "s=" and "d=" to
> identify a single source. Thus a new Subject: is born.
> 
> It's true key rotation is rare. People are figuring out how to do it,
> though. Due to the size and scope of email's installed base, it takes a
> really long time for the knowledge to slosh around the Internet. Using
> multiple CNAMEs, delegating sub-domains, even out-sourcing all things
> _domainkey.* is possible. Unfortunately there isn't good guidance on the
> pros and cons of each way, and so people implement quick and dirty 'cause
> they don't know any better.
> 
> Using selectors to identify a single source of email isn't right, IMO. Given
> the way things play out, once people are told that selectors are important
> because they're used to identify sources of email (doesn't even matter how
> true it is), then we'll be stuck with selectors being a component of
> reputation. People will make do with what they've got.
> 
> If nature abhors a vacuum, the missing piece is "what identifies a source?".
> Selectors might fill that hole unless real guidance is provided.
> 
> Using sub-domains to differentiate services works nicely. Today lack of
> clear guidance means a Domain Owner has to deal with a mashup of different
> ways to integrate with 3rd party senders. 3rd party senders make do with
> what they've got, and that is often very constrained.
> 
> Maybe such guidance should go into the "Usage Guide". Declaring which parts
> of the DMARC puzzle should be used to build reputation system seems pretty
> important if interoperability is the goal.

I think it depends on what is meant by 'source'.

Imagine a scenario where I'm the mail admin for a shop that has 5 outbound 
servers.  As a matter of security policy, private keys are generated on the 
machine that will use them and never transit the network.  For DKIM then, I 
have 5 selectors.  No problem.

Time passes.  I remember to do key rotation, but my colleagues that manage our 
DNS close the ticket that to add the records for the new keys after only 
publishing 4 of the 5 new records.

Since the DNS people closed my ticket as finished, I put my new keys in 
production and start using the new selectors.

Being a conscientious mail admin, I check my DMARC feedback reporting 
regularly.  To my dismay, I discover that over the next day or two my DKIM 
pass rate for direct mail goes from 99% to less than 80%.

If I have the selector, I can identify that all the unexpected failures come 
from a single system.  I can take it out of production while I trouble shoot 
and focus my efforts on what went wrong on with the key rollover for that one 
system.  Without the selector, I don't know if it's a single 'source' or 
multiple 'sources'.

In this context, having the selector in DMARC feedback reporting to help 
define a 'source' is really useful.

Using the selectors to segregate different 'sources' for reputation purposes 
is not (in this case).

Receivers know the selector.  If they feed domain and selector into their 
Bayesian processors and get a useful distinction, they are going to use it.  
No RFC will change that.  If there's some statistically significant difference 
in 'sources' identified that way, then that's their call.

I think selectors in DMARC reporting would be really useful.  For ARC though, 
I'm not at all convinced.  I can't think why, as a sender, I would care.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Fri, 07 Jul 2017 14:58:38 -0400

On 6/26/2017 5:26 PM, Gene Shuman wrote:
> I definitely support this idea, as having the selectors available is
> extremely useful to us as part of service authentication.  And putting
> them into the AR headers seems to be the appropriate solution.
>
> I guess the next question is how we would actually go about sending
> this information.  Something like header.s?

My Auth-Res processor passes the DKIM selector value as "header.s" and 
the DKIM identity value as "header.i" so my package would be 
supportive and ready for it.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Fri, 07 Jul 2017 15:09:06 -0400

On 7/7/2017 9:12 AM, Tim Draegen wrote:

> I just caught up on the "selectors in AAR" thread, but wanted to go
> back to this early statement about key rotation and pairing of "s="
> and "d=" to identify a single source. Thus a new Subject: is born.
>
> though.

In our case, since day 0 of DKIM, maybe a handful of times was the 
selector changed for our domains.  I think its basically an DNS 
"update" automation issue, i.e. its not "forced" or "scheduled" for 
rotation if automated DNS update is not in place.

-- 
HLS

---

From: Seth Blank <[email-masked]>
Date: Fri, 7 Jul 2017 13:33:58 -0700

> in 'sources' identified that way, then that's their call.

Agreed 100%

> I'm not at all convinced.  I can't think why, as a sender, I would care.

So this use case is exactly correct, and I think it very clearly
demonstrates the value of the selector when it comes to reporting back on
ARC in a DMARC report.

Take the following case, extending Scott's example:

When we have a direct sender -> receiver relationship, in aggregate, the
receiver will see 5 DKIM-Signatures, four of which pass and one of which
fails. This information can be reported back to the sender to fix the
broken key.

Now, with a sender -> intermediary -> receiver relationship (and assuming
the intermediary modifies the message and breaks the signature, so ARC is
needed for delivery), in aggregate, all 5 sender DKIM-Signatures will be
broken. Without a selector, it is impossible to disambiguate which keys are
problematic and need fixing since they all share the same header.d/header.i.

And to be very specific about this above case, in the aggregate for AAR for
i=1 you'd see "dkim=pass header.i=example.com" four times and "dkim=fail
header.i=example.com" once, but all signatures will fail to validate at the
receiver. Adding the selector makes it possible to disambiguate these
statuses so that the sender, to whom these selectors are meaningful, can
fix broken configurations.

Does this make sense or is the example and value of selectors still unclear?

Seth

---

From: Dave Crocker <[email-masked]>
Date: Fri, 7 Jul 2017 13:37:54 -0700

>     in 'sources' identified that way, then that's their call.

This was a hot topic when DKIM first came out.  It represents a failure 
to use or understand the role of selectors properly.  The reputation 
/should/ rely only on the domain name /without/ the selector, so the 
selector can be used only for administrative purposes, such as rolling 
over to a new key.

Note, for example, that including the selector in the reputation 
analysis means that the history of the actor is lost when a new selector 
is used.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Steve Atkins <[email-masked]>
Date: Fri, 7 Jul 2017 13:44:41 -0700

> On Jul 7, 2017, at 1:37 PM, Dave Crocker <[email-masked]> wrote:
> 
> This was a hot topic when DKIM first came out.  It represents a failure to use or understand the role of selectors properly.  The reputation /should/ rely only on the domain name /without/ the selector, so the selector can be used only for administrative purposes, such as rolling over to a new key.
> 
> Note, for example, that including the selector in the reputation analysis means that the history of the actor is lost when a new selector is used.

That a particular major ISP uses (or claims to use, or used to claim to use) selectors to identify particular senders is (or was, or was and continues to be) a major reason that some ESPs refuse to rotate keys at all. 

Cheers,
  Steve

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 07 Jul 2017 17:35:25 -0400

> Does this make sense or is the example and value of selectors still unclear?

If my mail flow was 100% indirect it would, but that's atypical.  If direct 
mails were at 98% and indirect was at 80% it wouldn't matter what ARC says, 
I'd consider it somebody else's problem.  Even if I had no direct mail and the 
indirect was 80%, I don't think I'd view what somebody told me about what 
somebody told them about mail I sent as a reliable basis for action.

I'd leave it out of ARC for now and focus on getting it into the DMARC 
aggregate reports.  Once it's there and there's some operator experience with 
the data, then we'll be in a better position to assess if there is utility for 
ARC.

At the moment, we're purely arguing theory.

Scott K

---

From: Seth Blank <[email-masked]>
Date: Fri, 7 Jul 2017 15:42:41 -0700

The philosophical questions about how DKIM should best be used, best
practices for selector usage, or how receivers determine reputation, are
besides a very practical concern here that we're trying to address:

As a domain owner, the keys I use to sign messages are well known to me.
Determining which key was used at the beginning of an ARC flow is
impossible without transmitting the selector.

On Fri, Jul 7, 2017 at 2:35 PM, Scott Kitterman <[email-masked]>
wrote:

> > > machine that will use them and never transit the network.  For DKIM
> then,
> > > I
> > > Time passes.  I remember to do key rotation, but my colleagues that
> manage
> > > our
> > > and focus my efforts on what went wrong on with the key rollover for
> that
> > > one

---

From: Dave Crocker <[email-masked]>
Date: Fri, 7 Jul 2017 16:43:20 -0700

> That a particular major ISP uses (or claims to use, or used to claim to use) selectors to identify particular senders is (or was, or was and continues to be) a major reason that some ESPs refuse to…

Then it would be helpful to the industry to attempt to get that ISP to 
change it's behavior.

Whether it would help to issue a BCP, which explicitly directs receivers 
not to factor selector into filtering analysis and provides a detailed 
explanation of why such factoring is problematic, is something I'll ask 
and then leave it to others to decide about...

d/

---

From: Dave Crocker <[email-masked]>
Date: Fri, 7 Jul 2017 16:45:19 -0700

> impossible without transmitting the selector.

transmitting to whom?  and the issue isn't carriage of the selector.  if 
you mean in reporting, that's fine.

the issue is whether selector is factored into filtering analysis, 
thereby defeating the ability to use it for strictly administrative 
purposes as was intended.

d/

---

From: Seth Blank <[email-masked]>
Date: Fri, 7 Jul 2017 16:51:01 -0700

> you mean in reporting, that's fine.

yes, 1000%

we are *only* discussing about a DMARC report, and transmitting the
selector via A-R/AAR so that it can be returned in a report.

> the issue is whether selector is factored into filtering analysis, thereby
> defeating the ability to use it for strictly administrative purposes as was
> intended.
>
>
> d/
>
> --
> Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 7 Jul 2017 22:54:51 -0700

> define a 'source' is really useful.

The DMARC report also includes other things that might be able to help you
identify the bad source, like the IP address.  But I do hear what you're
saying.  Just to be clear, I don't really have any issue with adding
selectors to DMARC reports.  My trepidation specifically involves using A-R
to transport the selector to wherever.

The purpose of A-R going back to RFC5451 was primarily to make available
(i.e., highlight) to users those portions of a message that were primary
input to an authentication decision: "We validated signed content X against
a published key for domain Y and it passed" (for DKIM), or "we validated IP
address X against the policy for domain Y and it passed" (for SPF).  Given
most selectors out there, in my experience, identify time ranges for which
the keys are meant to be valid, or are otherwise not names meaningful to an
end user, providing the selector name seems antithetical to this purpose;
what, for example, would a user do with the knowledge that ietf.org's
"ietf1" key or kitterman.com's "201409" key or Scott's hypothetical
"machine-number-5" key signed this message?  If Gmail showed that,
highlighted, on a message, would it help or confuse a typical user?  I
think the latter, and if that's the case, I would argue that A-R is not the
place to put it.

This smells like feature creep to me.  If consensus is that it's good
feature creep, then that's what we do, but I'd like to know that we're sure
we want to water down A-R's definition in this way.  I don't have a problem
with having some way to get the selector into the DMARC report, but I'm not
convinced A-R is the right or only way to do it.

-MSK

---

From: Seth Blank <[email-masked]>
Date: Fri, 7 Jul 2017 23:12:15 -0700

On Fri, Jul 7, 2017 at 10:54 PM, Murray S. Kucherawy <[email-masked]>
wrote:

> selectors to DMARC reports.
>

Great

> My trepidation specifically involves using A-R to transport the selector
> to wherever.
>
> convinced A-R is the right or only way to do it.

The way I read it, the consensus in this thread and others is that
selectors and source ip make sense to transmit for DMARC report reasons,
but where/how they should be transmitted does not have consensus.

An earlier thread discussed putting this information in the AAR, but the
consensus in that thread was that the AAR definition in the spec should be
kept as minimal as possible, and a better place for the selector was the
A-R, but the source ip didn't belong in the A-R at all.

If neither of these pieces of information make sense in an A-R, to me it
makes sense to revisit the conversation around transmitting via AAR instead
of discussing new headers altogether (which is where the source ip
conversation went), which definitely does feel like feature creep.

Or maybe, put a different way, the question is: what's the simplest way,
with the least delta to the spec, that allows for transmission of selectors
and source ip? This would enable DMARC reports for messages delivered due
to ARC to have the same report payload as messages delivered directly.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 7 Jul 2017 23:29:59 -0700

> to ARC to have the same report payload as messages delivered directly.

I would suggest not specifying it at all, and letting implementations
figure out some private way to do it that works for them.

To give a real example, OpenARC could put it in A-R or A-A-R if it wants
to, to be consumed downstream by OpenDMARC.  But the ARC RFC doesn't have
to say that this is "the" way to do it.  This is fine since RFC7601 says
anything else that ever sees an unknown ptype.property pairing ("header.s",
for example) is not supposed to use it.

-MSK

---

From: Seth Blank <[email-masked]>
Date: Sat, 8 Jul 2017 14:08:06 -0700

> for example) is not supposed to use it.

I think it needs to be specified. Receivers construct DMARC reports in a
known manner, they shouldn't need to guess how to get the appropriate
information out of ARC headers in an intermediary-implementation-specific
manner. The spec should make it unambiguous how information can be
transmitted to the receivers in a consistent and interoperable manner.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 8 Jul 2017 21:25:09 -0700

> transmitted to the receivers in a consistent and interoperable manner.

So evidently we've got a conflict between what A-R was intended to be used
for, and an apparent need to create a channel between ARC and DMARC to
relay stuff like selectors and source IP addresses.  If consensus exists
that the need is real and in scope for this WG, we either need to come to
consensus on allowing feature creep of A-R, or come up with another way to
meet that need.

With respect to the source IP in particular, we had that battle all the way
up to a formal appeal to the IESG and that too was resolved with a decision
that such details weren't appropriate for A-R.  This resulted in what is
now Appendix C of RFC7601, and the client IP address was left out.

Also, assuming you're referring to the ARC base draft, I don't agree that
"with the least delta to the spec" is a legitimate constraint here.

-MSK

---

From: Laura Atkins <[email-masked]>
Date: Sun, 9 Jul 2017 09:24:24 -0700

> On Jul 7, 2017, at 4:43 PM, Dave Crocker <[email-masked]> wrote:
> 
> Then it would be helpful to the industry to attempt to get that ISP to change it's behavior.

I believe it’s no longer the case. There was quite a bit of work done to convince them this was a bad idea. The ISP in question has also changed hands and mail handling is being transferred to another backend. 

But they were rather open about it for a while. Part of it was requiring senders to pre-register selectors.

laura 

-- 
Having an Email Crisis?  800 823-9674 

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741		

Email Delivery Blog: http://wordtothewise.com/blog

---

From: Dave Crocker <[email-masked]>
Date: Sun, 9 Jul 2017 11:38:22 -0700

On 7/9/2017 9:24 AM, Laura Atkins wrote:
> Part of it was requiring senders to pre-register selectors.

wow.  that is (or, I guess, was) such a distinctly misguided 
understanding of the role of selectors that it's impressive.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 09 Jul 2017 19:24:58 +0000

>understanding of the role of selectors that it's impressive.

In the early days of SPF/Sender ID there was one major free webmail provider that had such an odd implementation that if your SPF record wasn't already in their DNS cache, the check would inevitably time out and fail.  Their solution was to provide a method for domain owners to manually submit "missing" records.

There's no end to the inventiveness of such entities.

Scott K

---

From: Brandon Long <[email-masked]>
Date: Sun, 9 Jul 2017 17:20:36 -0700

Can someone send a pointer the archive for the ip question for spf?  I'd
love to read about it.

Brandon

On Jul 8, 2017 9:25 PM, "Murray S. Kucherawy" <[email-masked]> wrote:

>> On Fri, Jul 7, 2017 at 11:29 PM, Murray S. Kucherawy <[email-masked]
>> > wrote:
>>
>>>> Or maybe, put a different way, the question is: what's the simplest
>>>> way, with the least delta to the spec, that allows for transmission of
>>>> selectors and source ip? This would enable DMARC reports for messages
>>>> delivered due to ARC to have the same report payload as messages delivered
>>>> directly.
>>>>
>>>
> With respect to the source IP in particular, we had that battle all the
> way up to a formal appeal to the IESG and that too was resolved with a
> decision that such details weren't appropriate for A-R.  This resulted in
> what is now Appendix C of RFC7601, and the client IP address was left out.
>

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 10 Jul 2017 01:26:00 +0000

This isn't a bad place to start:

http://mipassoc.org/pipermail/mail-vet-discuss/2009q1/000570.html

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 10 Jul 2017 00:27:19 -0700

> transmitted to the receivers in a consistent and interoperable manner.

How do receivers include the source IP address in DMARC records today, when
A-R doesn't give it to them?

-MSK

---

From: Brandon Long <[email-masked]>
Date: Mon, 10 Jul 2017 12:48:53 -0700

On Mon, Jul 10, 2017 at 12:27 AM, Murray S. Kucherawy <[email-masked]>
wrote:

> How do receivers include the source IP address in DMARC records today,
> when A-R doesn't give it to them?
>

I think this highlights the challenge we're having with this conversation.

Today, DMARC reports only contain information about the current hop where
the report is being generated.

Obviously, at the current hop, any information available to that hop, such
as IP and selectors, can be logged directly for generating the report.

We're talking about how, with ARC, we want to include information in the
DMARC report from the previous hops.  The best way to pass information from
previous hops is through the AAR.

It might be possible to parse the Received headers for IPs, or extract the
selectors by walking the header.b information that is in the AAR headers,
but obviously being more direct is preferred.

Brandon

---

From: Brandon Long <[email-masked]>
Date: Mon, 10 Jul 2017 12:53:38 -0700

On Fri, Jul 7, 2017 at 6:12 AM, Tim Draegen <[email-masked]> wrote:

> I just caught up on the "selectors in AAR" thread, but wanted to go back
> to this early statement about key rotation and pairing of "s=" and "d=" to
> Using selectors to identify a single source of email isn't right, IMO.
> Given the way things play out, once people are told that selectors are
> important because they're used to identify sources of email (doesn't even
> matter how true it is), then we'll be stuck with selectors being a
> component of reputation. People will make do with what they've got.
>
> If nature abhors a vacuum, the missing piece is "what identifies a
> source?". Selectors might fill that hole unless real guidance is provided.
>
> Maybe such guidance should go into the "Usage Guide". Declaring which
> parts of the DMARC puzzle should be used to build reputation system seems
> pretty important if interoperability is the goal.
>

But selectors do identify a source, to some extent.  Even with rotation, if
I hand out a key to some service or just give them a couple CNAMES, its
obvious that's a different source than another.  And it's that ability
we're talking about using with DMARC reporting and the companies trying to
get folks to p=reject.

Yes, building reputation on selectors is a really bad idea when it comes to
rotation.  I'm sure we can all figure out how to handle rotation to ramp
slowly to work around that, but that seems like an insane extra step to add
to something that is already too hard for most folks to do as often as they
should.

Brandon

---

From: Steve Atkins <[email-masked]>
Date: Mon, 10 Jul 2017 13:52:17 -0700

> On Jul 10, 2017, at 12:53 PM, Brandon Long <[email-masked]> wrote:
> 
> 
> 
> But selectors do identify a source, to some extent.  Even with rotation, if I hand out a key to some service or just give them a couple CNAMES, its obvious that's a different source than another.  And it's that ability we're talking about using with DMARC reporting and the companies trying to get folks to p=reject.
> 
> Yes, building reputation on selectors is a really bad idea when it comes to rotation.  I'm sure we can all figure out how to handle rotation to ramp slowly to work around that, but that seems like an insane extra step to add to something that is already too hard for most folks to do as often as they should.

I don't foresee key rotation being commonplace until there's something - either within the spec or outside it - that treats old keys differently to new keys. Not even if an RFC and several major ISPs loudly proclaim that they track reputation and identify sources based solely on the d= (or i=, if they want to) and not via a selector. Some operational risk vs none (other than the risk of key compromises) is an easy enough decision to make.

If a large recipient ISP, say, started keeping track of the first time it saw any public key and treated any mail using old keys with disdain then people would jump on key rotation right away. Much the same approach as pushing bulk senders to send all their mail, even the least confidential junks mail, via TLS by making unencrypted mail less attractive to the recipient.

But if the key compromises remain mostly theoretical there doesn't seem much point to worrying about it, other than the aesthetics of the thing.

Cheers,
  Steve

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 11 Jul 2017 09:12:15 -0700

On Mon, Jul 10, 2017 at 12:48 PM, Brandon Long <[email-masked]> wrote:
>
>
> On Mon, Jul 10, 2017 at 12:27 AM, Murray S. Kucherawy <[email-masked]
> > wrote:
>

> "with the least delta to the spec" is a legitimate constraint here.

As I see it, there are two possible approaches to address this dilemma:
1) Include the additional information in the AAR which is wanted downstream
for a DMARC report to be emitted from a receiver N hops away - this
requires additional fields to the basic RFC7601 A-R spec
2) Create a fourth member of the ARC set of headers to convey this
additional information (this is partially was was proposed with the
Origin-IP header, but not fleshed out enough to be really useful in an
unlimited number of hops scenario).

I'm somewhat opposed to creating a fourth member for an ARCset because I
think that increases the fragility of the chain, but, OTOH, it may be an
easier delta for new implementers than creating a basic A-R and an
"enhanced" version to post as the AAR. I'm definitely opposed to making
these fields *required* because that would require ARC validation to parse
the AAR (or fourth header) to determine validity and we've tried to stay
away from that (leaving it to the report generating code to have to worry
about AAR contents).

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 11 Jul 2017 20:40:50 -0700

On Tue, Jul 11, 2017 at 9:12 AM, Kurt Andersen (b) <[email-masked]> wrote:

>
> 1) Include the additional information in the AAR which is wanted
> downstream for a DMARC report to be emitted from a receiver N hops away -
> this requires additional fields to the basic RFC7601 A-R spec
>

This seems to be the least painful, since ARC "owns" AAR and is thus free
to do what it wants here, but then there's no way to do what you want in
non-ARC environments which I infer would be a helpful thing from Seth's
comments.

> unlimited number of hops scenario).

I think that's even cleaner.

> think that increases the fragility of the chain,
>

How is it any more fragile than already having to stack and hash ordered
groups of three ordered things?

> but, OTOH, it may be an easier delta for new implementers than creating a
> basic A-R and an "enhanced" version to post as the AAR. I'm definitely
> opposed to making these fields *required* because that would require ARC
> validation to parse the AAR (or fourth header) to determine validity and
> we've tried to stay away from that (leaving it to the report generating
> code to have to worry about AAR contents).
>

You would just need to be clear in prose how its presence and/or absence is
expected to affect interoperability (if at all).

-MSK