Re: [ietf-dkim] Key rotation
On Thu, Sep 9, 2010 at 5:21 PM, J.D. Falk jdfalk-li...@cybernothing.orgwrote: On Sep 9, 2010, at 9:57 AM, Mark Martinec wrote: Rumor has is that some large players (such as Yahoo!) are disregarding such ephemeral property of a selector and are trying to associate a reputation scheme based on both the domain *and* the selector. That rumour is based on a presentation I gave in 2006 or so, while working at Yahoo!. Within hours, Dave Crocker had convinced me that tying reputation to the selector was a bad idea. Please help me quash the rumour, there's enough baseless FUD already. http://feedbackloop.yahoo.net/ Step 2 doesn't help. (yes, you can put * for all selectors, but asking for one when it isn't really needed leads to FUD). -- Jeff Macdonald Ayer, MA ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Key rotation
On Fri, Sep 10, 2010 at 6:55 AM, Jeff Macdonald macfisher...@gmail.comwrote: On Thu, Sep 9, 2010 at 5:21 PM, J.D. Falk jdfalk-li...@cybernothing.orgwrote: On Sep 9, 2010, at 9:57 AM, Mark Martinec wrote: Rumor has is that some large players (such as Yahoo!) are disregarding such ephemeral property of a selector and are trying to associate a reputation scheme based on both the domain *and* the selector. That rumour is based on a presentation I gave in 2006 or so, while working at Yahoo!. Within hours, Dave Crocker had convinced me that tying reputation to the selector was a bad idea. Please help me quash the rumour, there's enough baseless FUD already. http://feedbackloop.yahoo.net/ Step 2 doesn't help. (yes, you can put * for all selectors, but asking for one when it isn't really needed leads to FUD). Yeah, I've always thought this process was a bit odd. I began to question if it even mattered to them and, furthermore, how much weight they were actually putting on Domain vs. IP for reputation. Alex Soto a...@thesotos.org ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Key rotation
http://feedbackloop.yahoo.net/ Step 2 doesn't help. (yes, you can put * for all selectors, but asking for one when it isn't really needed leads to FUD). A selector can of course be in a sub-domain format, such as september.dialup._domainkey.example.net I wonder if they considered letting you enter *.dialup or somesuch? Obviously, requiring or using a fixed name selector is something no sensible person should be advocating. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Key rotation
I wonder if they considered letting you enter *.dialup or somesuch? I dunno, but I think the last time something like this came up, we agreed that if you want to have two separate reputation streams, they should have different d= rather than different selectors. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Key rotation
Mark Delany wrote: I believe the general thrust is that DKIM keys are ephemeral so no one should rely on there long-term presence. [...] With each key there is an associated selector:domain pair, so with a key rotation comes the change of a selector. Such a purpose of a selector is clearly documented in the DKIM rfc. Rumor has is that some large players (such as Yahoo!) are disregarding such ephemeral property of a selector and are trying to associate a reputation scheme based on both the domain *and* the selector. If such approach catches up, it would mean the end of a free choice of domains to roll up new signing keys periodically. Are my worries warranted? Is there anything than can be done about it to prevent such practice? Mark ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Key rotation
This points up an issue with the use of selectors. Some signers use selectors to differentiate streams of mail. This plays in to what you describe Yahoo! as doing for reputation. We will be using the approach you describe for key rotation. Given that my goal is to rotate keys quarterly (more for operational considerations than security) this would be a problem if Yahoo! is really going this route. Mike -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Mark Martinec Sent: Thursday, September 09, 2010 12:57 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Key rotation Mark Delany wrote: I believe the general thrust is that DKIM keys are ephemeral so no one should rely on there long-term presence. [...] With each key there is an associated selector:domain pair, so with a key rotation comes the change of a selector. Such a purpose of a selector is clearly documented in the DKIM rfc. Rumor has is that some large players (such as Yahoo!) are disregarding such ephemeral property of a selector and are trying to associate a reputation scheme based on both the domain *and* the selector. If such approach catches up, it would mean the end of a free choice of domains to roll up new signing keys periodically. Are my worries warranted? Is there anything than can be done about it to prevent such practice? Mark ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Key rotation
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Mark Martinec Sent: Thursday, September 09, 2010 9:57 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Key rotation Mark Delany wrote: I believe the general thrust is that DKIM keys are ephemeral so no one should rely on there long-term presence. [...] With each key there is an associated selector:domain pair, so with a key rotation comes the change of a selector. Such a purpose of a selector is clearly documented in the DKIM rfc. Rumor has is that some large players (such as Yahoo!) are disregarding such ephemeral property of a selector and are trying to associate a reputation scheme based on both the domain *and* the selector. If such approach catches up, it would mean the end of a free choice of domains to roll up new signing keys periodically. Are my worries warranted? Is there anything than can be done about it to prevent such practice? It's not the first time I've heard that presented as a reputation idea. Off the top of my head, I think the solution to that would probably be the realization by such verifiers that they're needlessly throttling good domains using such a scheme, causing them more headaches than they solve. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Key rotation
On Sep 4, 2010, at 9:31 PM, Steve Atkins wrote: The whole point of rotating keys is so that loss of an old private key isn't a risk. Given that, I think that even if you're fairly sure that a key pair hasn't been compromised then you should remove the public key as soon as is reasonable after you stop signing with the private key - as the private key continues to be a high value target until the public key is removed. Eight days is as short as I'm comfortable with, so that's as soon as is reasonable for me. ...but what would be as long as I'm comfortable with? Have we seen DKIM private keys compromised due in large part to leaving the public keys in rotation for too long... and what was too long in those instances. I'd be surprised to discover many senders are rotating keys every eight days. -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Key rotation
On 09/09/2010 11:12 AM, McDowell, Brett wrote: On Sep 4, 2010, at 9:31 PM, Steve Atkins wrote: The whole point of rotating keys is so that loss of an old private key isn't a risk. Given that, I think that even if you're fairly sure that a key pair hasn't been compromised then you should remove the public key as soon as is reasonable after you stop signing with the private key - as the private key continues to be a high value target until the public key is removed. Eight days is as short as I'm comfortable with, so that's as soon as is reasonable for me. ...but what would be as long as I'm comfortable with? Have we seen DKIM private keys compromised due in large part to leaving the public keys in rotation for too long... and what was too long in those instances. I'd be surprised to discover many senders are rotating keys every eight days. I think he's talking about keeping a key around 8 days after it's been deprecated so that in-flight mail will still verify. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Key rotation
On Sep 9, 2010, at 11:12 AM, McDowell, Brett wrote: On Sep 4, 2010, at 9:31 PM, Steve Atkins wrote: The whole point of rotating keys is so that loss of an old private key isn't a risk. Given that, I think that even if you're fairly sure that a key pair hasn't been compromised then you should remove the public key as soon as is reasonable after you stop signing with the private key - as the private key continues to be a high value target until the public key is removed. Eight days is as short as I'm comfortable with, so that's as soon as is reasonable for me. ...but what would be as long as I'm comfortable with? Have we seen DKIM private keys compromised due in large part to leaving the public keys in rotation for too long... and what was too long in those instances. That question doesn't make any sense. I'd be surprised to discover many senders are rotating keys every eight days. I didn't suggest rotating keys every eight days. Rather, I suggested leaving the public keys in place for 8 days after removing the associated private key. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Key rotation
On Sep 9, 2010, at 9:57 AM, Mark Martinec wrote: Mark Delany wrote: I believe the general thrust is that DKIM keys are ephemeral so no one should rely on there long-term presence. [...] With each key there is an associated selector:domain pair, so with a key rotation comes the change of a selector. Such a purpose of a selector is clearly documented in the DKIM rfc. Rumor has is that some large players (such as Yahoo!) are disregarding such ephemeral property of a selector and are trying to associate a reputation scheme based on both the domain *and* the selector. I don't believe this is true. I think it's being disseminated by bulk mail folks who don't really understand what a DKIM selector is for and who love to speculate about the dead goats and pentagrams used at large consumer ISPs. There's endless speculation amongst bulk mailers about the reputation tracking and spam filtering black boxes used by the big consumer ISPs, and it's amazing how far off into the weeds it gets (AOL won't deliver email with a pink background, Gmail blocks all email with a facebook URL, Yahoo will block your mail if you change your DKIM selector, ...) If such approach catches up, it would mean the end of a free choice of domains to roll up new signing keys periodically. Are my worries warranted? I don't believe so. Without hard data or an official statement from major ISPs that they're doing something stupid with DKIM selectors I think you're safe to ignore the issue. Is there anything than can be done about it to prevent such practice? Ignore the FUD. Use d= as your reputation key, with subdomains for different mail streams. Leave selectors for key rotation[1] and multiple sender support[2]. Cheers, Steve [1] http://labs.wordtothewise.com/keydancer/ [2] http://dkimcore.org/deployment/esp.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Key rotation
On 09/09/2010 09:57 AM, Mark Martinec wrote: Mark Delany wrote: I believe the general thrust is that DKIM keys are ephemeral so no one should rely on there long-term presence. [...] With each key there is an associated selector:domain pair, so with a key rotation comes the change of a selector. Such a purpose of a selector is clearly documented in the DKIM rfc. Rumor has is that some large players (such as Yahoo!) are disregarding such ephemeral property of a selector and are trying to associate a reputation scheme based on both the domain *and* the selector. If such approach catches up, it would mean the end of a free choice of domains to roll up new signing keys periodically. Are my worries warranted? Is there anything than can be done about it to prevent such practice? I'm pretty sure that Mark isn't an advocate such a practice, but let's face reality here: RBL's use IP addresses which are far more transient yet we somehow cope. And I don't think that one of the worst problems with RBL's vs. IP addresses (collateral damage when IP addresses change hands) even applies here. But if a reputation service isn't prepared for key rollover on selectors, I'd look for another one because they're incompetent. What else is a DKIM signer supposed to do if a key compromised? Blast out memory eraser rays? Mike Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Key rotation
On Sep 9, 2010, at 2:26 PM, Steve Atkins wrote: On Sep 9, 2010, at 11:12 AM, McDowell, Brett wrote: I'd be surprised to discover many senders are rotating keys every eight days. I didn't suggest rotating keys every eight days. Rather, I suggested leaving the public keys in place for 8 days after removing the associated private key. My apologies, I completely misunderstood what you were suggesting in this thread. But at least now I know you aren't crazy (at least not for your position on this issue ;-) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Key rotation
On Sep 9, 2010, at 9:57 AM, Mark Martinec wrote: Rumor has is that some large players (such as Yahoo!) are disregarding such ephemeral property of a selector and are trying to associate a reputation scheme based on both the domain *and* the selector. That rumour is based on a presentation I gave in 2006 or so, while working at Yahoo!. Within hours, Dave Crocker had convinced me that tying reputation to the selector was a bad idea. Please help me quash the rumour, there's enough baseless FUD already. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Key rotation
On Sep 9, 2010, at 9:57 AM, Mark Martinec wrote: Rumor has is that some large players (such as Yahoo!) are disregarding such ephemeral property of a selector and are trying to associate a reputation scheme based on both the domain *and* the selector. On Thursday September 9 2010 23:21:55 J.D. Falk wrote: That rumour is based on a presentation I gave in 2006 or so, while working at Yahoo!. Within hours, Dave Crocker had convinced me that tying reputation to the selector was a bad idea. Please help me quash the rumour, there's enough baseless FUD already. Thanks! That is what I was hoping to hear! Mark ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Key rotation
On Sat, Sep 04, 2010 at 01:41:41PM -0700, Steve Atkins allegedly wrote: Do we have any thoughts on 1. how often keys might sensibly be rotated and 2. how long public keys should remain visible after the private key has been rotated out? I believe the general thrust is that DKIM keys are ephemeral so no one should rely on there long-term presence. Your verifying MTA should annotate inbound mail appropriately so that subsequent reliance on the public key is not needed. Authentication-Results header being a good place to store what is needed here. (I know you know this, Steve. I'm just setting the stage). In that light, I would expect that a public key only needs to stay around as long as an email can remain in-transit plus some fudge. Maybe seven days or thereabouts? Turning the question back to you. Is there any motive for removing public keys rapidly apart from when they've been compromised? I can't think of any obvious reason why you'd want to do this, so I'm curious to hear of any use-cases you have in mind that warrant rapid removal. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Key rotation
On Sep 4, 2010, at 2:55 PM, Mark Delany wrote: On Sat, Sep 04, 2010 at 01:41:41PM -0700, Steve Atkins allegedly wrote: Do we have any thoughts on 1. how often keys might sensibly be rotated and 2. how long public keys should remain visible after the private key has been rotated out? I believe the general thrust is that DKIM keys are ephemeral so no one should rely on there long-term presence. Your verifying MTA should annotate inbound mail appropriately so that subsequent reliance on the public key is not needed. Authentication-Results header being a good place to store what is needed here. (I know you know this, Steve. I'm just setting the stage). Yup. Phrased more simply, the public key should be available when the email hits the recipients final MX, but shouldn't be needed after that. In that light, I would expect that a public key only needs to stay around as long as an email can remain in-transit plus some fudge. Maybe seven days or thereabouts? Funny you should say that. I'm using 8 days, based on If mail hasn't been delivered in 7 days, it probably won't be plus a one day fudge factor. Turning the question back to you. Is there any motive for removing public keys rapidly apart from when they've been compromised? I can't think of any obvious reason why you'd want to do this, so I'm curious to hear of any use-cases you have in mind that warrant rapid removal. The whole point of rotating keys is so that loss of an old private key isn't a risk. Given that, I think that even if you're fairly sure that a key pair hasn't been compromised then you should remove the public key as soon as is reasonable after you stop signing with the private key - as the private key continues to be a high value target until the public key is removed. Eight days is as short as I'm comfortable with, so that's as soon as is reasonable for me. If you know that a private key has been compromised then you probably kill the public key ASAP - the risk of misuse outweighing the loss of signature of any emails on the wire. Though if I knew the key had been compromised because I'd just fired a sysadmin, rather than because I'd seen spam using it, I'd probably rotate the private key, then leave the public key up for a few hours, as the vast majority of email will have been delivered, and the public key checked, in that time. Lists of email addresses walk out of ESPs all the time, and I'm expecting DKIM private keys to have a similar level of leakage. If I were setting policy at an ESP I'd want to rotate keys pretty regularly, and kill public keys as soon as possible in order to reduce their value to insiders. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Key rotation
Mark Delany wrote: On Sat, Sep 04, 2010 at 01:41:41PM -0700, Steve Atkins allegedly wrote: Do we have any thoughts on 1. how often keys might sensibly be rotated and 2. how long public keys should remain visible after the private key has been rotated out? I believe the general thrust is that DKIM keys are ephemeral so no one should rely on there long-term presence. Your verifying MTA should annotate inbound mail appropriately so that subsequent reliance on the public key is not needed. Authentication-Results header being a good place to store what is needed here. (I know you know this, Steve. I'm just setting the stage). In that light, I would expect that a public key only needs to stay around as long as an email can remain in-transit plus some fudge. Maybe seven days or thereabouts? I believe this was the general view when it was this discussed back in 2006 few years back. I also wrote an I-D called DKIM-RCVD describing the time shifting issue and a possible solution to address it using a DKIM-Received: header idea: http://tools.ietf.org/html/draft-santos-dkim-rcvd-00 A proposal offering partial DKIM verification support to help resolve premature DKIM signature expiration and key revocation related problems associated with time shifted DKIM verifier applications. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Key rotation
Steve Atkins wrote: Do we have any thoughts on 1. how often keys might sensibly be rotated and 2. how long public keys should remain visible after the private key has been rotated out? The WG discussed this around 2006. The DKIM-RCVD I-D I wrote summarizes the timing issues from the discussions and also offered a way to help resolve this issue: http://tools.ietf.org/html/draft-santos-dkim-rcvd-00 There are three basic timing points: T1 - delivery time T2 - MFA (Mail Filtering Agent) process time T3 - MUA process/read/view time T1 is 7 days based on DKIM recommendations and adequately covers the SMTP recommendations of 4-5 retry days. So at a minimum the key retention time should be 7 days. But there is a T2 gap time when the MFA gets it. This time will mostly likely pretty short. And there is a T3 gap between MFA and by the time the MUA gets it. Who knows what T3 is, but it could be pretty long, i.e. a user goes on vacation or simply reads his mail once per day or whatever. So T3 is help consider possible MUAs with DKIM verification plug-ins. Since T3 can be low to high time significant, the I-D proposed a method whereby the middle ware (DKIM verifier or not) will create/add a DKIM-Received with your public key information. This way by the time it is actually needed by a verifier, it will have the old public key information in DKIM-Received. I also suggested that this DKIM-Received header can be used a migration idea for those systems not yet ready to sign or verify but can get the information and store in the header in case there will be a long time-shifted verification period that exceeds the domains key expiration. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
