On Friday, July 07, 2017 09:12:37 AM Tim Draegen wrote: > > On Jul 5, 2017, at 6:33 PM, Murray S. Kucherawy <[email protected]> > > 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.
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 _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
