> 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. -= Tim
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
