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.