Sam Hartman wrote:
I think you're assuming something about the way the reputation system
works; a large domain will hopefully still have an overwhelming majority
of "desirable" messages and that might factor into the reputation too.
The reputation might also depend on the responsiveness of the domain
when a problem is discovered. Or perhaps this is an argument for some
combination of reputation and accreditation.
The point of MASS is to make it possible to have the infrastructure
necessary to build up reputation about a domain and to have strong
enough authentication that this reputation is meaningful.
I consider the design of a reputation system that works and can't be
"gamed" to be a very non-trivial exercise.
Not if they read section section 9.1.4, "Message Replay Attack", of the
IIM draft. We have tried to be as upfront as possible about the
limitations of message signing.
The attack described in section 4.1 is a real attack against the MASS
proposals in that it gives someone the necessary cryptographic
information to do something bad to your reputation and to bind it
authentically to you.
Saying that it is also an attack against mail without MASS is true but
not sufficient. The casual reader, looking at MASS, unaware of that
issue will assume that MASS is not vulnerable to that attack.
There's a related attack that actually worries me more. Suppose someone
sends some spam to (for example) an ietf.org mailing list, where it gets
[re-]signed. If this message is replayed widely, it looks like ietf.org
is generating lots of spam, and it didn't even come from a user with an
At one point I suggested that maybe mailing lists should only sign
messages that were received with a valid signature, but others pointed
out that there is value in confirming the source as the mailing list
even if the sender of the input message didn't sign it. But one thing I
think hasn't been addressed adequately in any of the proposals is
whether or how a re-signer of a message indicates whether the message
they got had a valid signature (and from whom). That, in turn, needs to
be thought out carefully so that it doesn't turn into a mechanism for
joe-jobbing another domain (by pretending to be a mailing list and
sending signed messages saying the other domain sent out signed messages
which turn out to be spam).
Agreed. And we need to consider whether, given its blemishes, MASS is
adding value nonetheless.
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.
If a MASS document were published within the IETF it would need to
discuss this issue.
I think some of the issue is that calling it "replay attack" might make
one think that it would be fixed by better protocol design. I don't
think that's the case here; message replay is a requirement of quite a
few legitimate use cases for email.
If you don't want to call it a replay attack, that's fine with me. At
the crypto protocol level it is a replay; thinking of it that way may
or may not help you to understand it.