> On Jul 10, 2017, at 12:53 PM, Brandon Long <[email protected]> wrote: > > > > On Fri, Jul 7, 2017 at 6:12 AM, Tim Draegen <[email protected]> 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. > > 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 _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
