On Thu, 10 Feb 2005, Sam Hartman wrote:
It is entirely appropriate to consider the effects of that attack when
evaluating whether MASS actually solves a problem. It is entirely
appropriate to try and design MASS to prevent that attack, although as
others have pointed out doing so seems to violate other constraints.
Ok, if you are saying we can design to prevent this attack, can you be more
specific as to how? And note that some of the constraints companies like
yahoo have put in on their proposal are not necesserily good for everyone
concerned with mass effort so the constraints should be considered flexible,
after all this is ietf effort (or rather it should have been :).
If a MASS document were published within the IETF it would need to
discuss this issue.
If you don't want to call it a replay attack, that's fine with me.
I have not heard anybody being against calling it "replay attack", its one
of variations of it. The point however is that it may not be possible to
prevent it and still allow for email forwarding. For example lets take
already developed email security standarding like S/MIME, as I have
mentioned it was possible for S/MIME signed email to have been encapsulated
within email forwarded by mail list to multiple recepients and not only
that but when I clicked Ctrl-E in pine to see security information, it
showed the original S/MIME certificate but there was no mention that
this certificate is only valid for part of the message and as such it
even gave appearance to user that text in mail message footer was also
securely signed data, I believe the same is also true for windows MUAs
like outlook. So what do you want to call it if not a "replay" attack?