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: ietf-dkim(_at_)mipassoc(_dot_)org
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