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 protected]> wrote: > On Friday, July 07, 2017 01:33:58 PM Seth Blank wrote: > > On Fri, Jul 7, 2017 at 7:11 AM, Scott Kitterman <[email protected]> > > > > wrote: > > > 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. > > > > Agreed 100% > > > > > 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. > > > > 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? > > 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 > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
