I don't agree with John about number of issues on how mass mail signatures
are to be checked but in this thread he's right on target. There is no way
we can completely prevent replay attacks with signatures, best we can do
is to prevent changing important characteristics and embed time-stamp and
expiration in the signature so that trying to reuse somebody else's email
would be difficult if its way after its been sent.
Obviously having per-sender keys is also useful in case somebody is
replaying the signature and sender wants to deactivate the key, but it
creates an obvious problem for large companies that have to maintain large
number of keys (so one can gain some flexibility at the expense of
increase maintenance complexity - it would however be good for sender to
be able to pick which works best for them).
And, of course, because of this and several other issues, you just can't
put all your trust in the mass signature (nor can you in SPF of similar
path-verification technology). Its combination that can provide proper
email security - and for such combination to work we MUST NOT HAVE
failure scenarios from either authentication system (i.e. you just
can't say if SPF fails, you should trust rely on mail signature and
assume everything is good if it passes).
On 5 Feb 2005, John Levine wrote:
draft-housley-mass-sec-review-00.txt
Most of it's pretty good, but section 4.1 on replay attacks is
just wrong. It misunderstands what signatures do.
The only difference between a replay attack and normal mail forwarding
is intent. The bits are the same. I see a few possible ways that one
might try to deter replay attacks, none of which strike me as being at
all practical.
One is to count the number of times that a signature is checked, and
to stop saying yes when it's been checked too many times or it's been
too long since the message was sent for some versions of too many and
too long. The question of what those values might be has been argued
at length elsewhere, and the short version is that there's no value of
them that would both permit the kinds of mail that people really send
and would stop replay attacks. There's also the issue that for large
mail systems, maintaining a database of per message signatures and the
number of times each one has been checked, and querying and updating
such a database in real time is beyond the state of the database art.
(See the SES list archives for way too much bickering on this point.)
The extreme case is to permit checking only once, in which case the
signature check becomes a path verification. We already know all the
problems with path verification.
For this reason, mail signatures can't be used to deter replay
attacks. As I've said before, all signatures can do is tell you who
to blame if you get a message you don't like. You can't use them by
themselves to distinguish wanted from unwanted mail or spam from
not-spam. Where they are useful is in combination with reputation
systems and, I suspect, with existing path checking systems that let
you reject paths that don't send useful mail (ie DNSBLs.)
Regards,
John Levine, johnl(_at_)iecc(_dot_)com, Primary Perpetrator of "The Internet
for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"I shook hands with Senators Dole and Inouye," said Tom, disarmingly.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net