On Wed, Jul 5, 2017 at 3:33 PM, Murray S. Kucherawy <superu...@gmail.com> wrote:
> On Fri, Jun 23, 2017 at 3:17 PM, Brandon Long <bl...@google.com> wrote: > >> On Wed, May 31, 2017 at 10:07 PM, Murray S. Kucherawy < >> superu...@gmail.com> wrote: >> >>> On Thu, May 4, 2017 at 4:19 PM, Peter Goldstein <pe...@valimail.com> >>> 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? > 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 > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
