From: John Levine
Sent: Saturday, September 18, 2004 6:42 PM
My prototype does put a timestamp in the signature, ...
That will prevent replay of old signatures, but not of fresh ones.
Correct. That's not a bug. That's what it's designed to do.
So you want to get replay attacks based on freshly harvested signatures?
It is increasingly clear that whatever problem SES is purporting to
solve is unrelated to any problem that I can identify in the real world
so I'm out of here. Bye.
I find your attitude curious. Where shall I start?
No one who currently uses a signed envelope protocol experiences replay
because you can count the number of implementations on the fingers of one
hand. As more sites use this, the situation will change. Trojaned PC's
exist and will continue to do so, and when there are enough sites using
signed envelopes, whether for blowback protection or authentication, it will
become worthwhile to exploit. Ignoring the problem will not make it go
away.
Even if I were to agree with you on this particular issue, there were a lot
of other people who saw this protocol and immediately felt that was a
serious weakness that needed to be addressed. Personally, I don't think it
will be as bad a problem as some other people have expressed, but it could
easily become a persistent nuisance. My approach has been to make the
likelihood of a replay attack achieving even a single delivery extremely
low. If that is made abundantly clear from the outset, my guess is that
spammers will probably not bother, since it is clear they will never earn a
nickel from it. If they decide to mount a retaliatory DDoS, there are far
more efficient mechanisms for which there are no effective defenses.
One of several real world problems that SES "purports" to solve is
authentication. Though you have clearly stated your preference for DK, SES
is a real alternative that is lighter weight and has a number of other
useful properties, including the ability to reject domain forgeries before
data with fewer issues than SPF. This is for real systems, not "toy
systems", and we will be doing some implementations on large sites for proof
of concept. Both our project and yours would benefit from other cluefull
people participating, but if you think it will turn out better if you do it
all yourself, that is your prerogative.
The SES work started long before you "re-invented it as BATV" (Meng Weng
Wong's words on SPF-Discuss on more than one occasion) and will continue
whether you choose to participate or not. We were actively working on these
ideas for some time before our forum was established, and the discussion
there has been very active, so I think we have something to contribute.
Since the BATV and SES groups started with the same basic idea, it would be
a pity not to collaborate. That appears to be your preference, but I hope
that your colleagues are still open to working together. If the other
members of your group feel as you do, we can proceed with our own
implementation and submit our own draft without the mutual benefit of
cooperation. What is the preference of the other members of the BATV group
and the chairs of the Mailsig group?
--
Seth Goodman