Appols for top posting, resticted messaging capability here
On the topic of rotating through keys we have a near term requirement to transition to the new digest algorithm that is to replace SHA-1 and SHA-256 in the next 3 years or so. We also need to have at the very least a contingency plan to move to use of ECC.
We cannot take those steps now and so we are going to end up with a situation where we need to attach two signatures, an RSA-SHA1 signature and an RSA-AHS or ECC-AHS signature. Its the only way that transition can be managed.
This process is likely to be driven in the federal space by an executive order fiat. So regardless of what you might think the security needs are for DKIM we should plan for the introduction of next generation algorithms.
Just in case folk get the wrong idea, I am not saying that RSA-2048 is immediately vulnerable. However there are applications where it will cease to be acceptable within relevant time horizons.
From: John Levine
Sent: Fri 14/10/2005 11:21 AM
To: [email protected]
Subject: [ietf-dkim] Re: what is DKIM for, was on multi-signatures
> For now, isn't it probably ok to add this to the to-do list and > continue to work on the threat analysis which was a show-stopper > last time? Yes, I suppose you're right. This disagreement about multiple signatures cuts to the heart of what DKIM is for. If, as Mike Thomas seemed to be saying, the most we can get from DKIM is another factor to toss into the spamassassin hopper, we're wasting our time. If we have a signature and a reputation for the signing domain, we should be able to skip the rest of the spam filtering mess. As I said in a previous message, the point of a DKIM signature is to pin the blame on a specific domain. This cuts both ways -- recipients can then use info about the domain to decide what to do with the message, and they can also use the message to update their info about the domain. Disregarding spammers who don't care about their reputations, this leads to a virtuous feedback loop in which domains benefit from signing mail that recipients like, feel some pain for signing mail that recipients don't want, and have an incentive to improve their practices. If we permit multiple signatures, that works a lot worse. In Jim Fenton's example where a friend resigns a spam from an all-419 domain, multiple signatures let the friend deflect the responsibility onto the original sender rather than fixing whatever caused him to sign and resend it. Eliot Lear points out, correctly, that a message's signing history is useful trace information. But trace info is different from responsibility info. This suggests to me that it is useful to define a way to record signature history, either as a new clause in a Received: header or perhaps a new trace header, different from a signature header to make it clear that it's for forensics, not for pinning blame. Finally, Dave Crocker suggests that multiple signatures may be useful for rotating through signing keys. With DK, I thought the plan was that you publish a new signing key and start signing with it, wait long enough for mail with the old key to be delivered, then withdraw the old key. Assuming that we agree that putting two mechanisms in a standard to do the same thing is a bad idea, what's the advantage of allowing multiple sigs? R's, John _______________________________________________ ietf-dkim mailing list http://dkim.org
_______________________________________________ ietf-dkim mailing list http://dkim.org
