On Fri, 2005-02-11 at 15:54 -0800, Jim Fenton wrote:
Sam Hartman wrote:
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 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.
This would be assuming reputation is based upon the remote IP address.
In such a case, server reputations can be retained by canceling abusive
accounts and monitoring logs. A signature however can be
"authenticated" regardless of the remote IP address, and hence canceling
accounts and monitoring logs alone would be ineffectual reputation
protection as abuse could continue unabated as "replays".
For the signature to provide significant value, it should be effective
at abating abuse. Being able to assert a domain sourced the initial
message has value, but only for a few cases where the signing domain and
mailbox-domain are significant and visible to the recipient. To obtain
wide spread deployment, the mechanism should confront broader issues of
abuse to justify the added expense. Here signatures can make dramatic
improvements by permitting centralization or localization of anti-abuse
I consider the design of a reputation system that works and can't be
"gamed" to be a very non-trivial exercise.
Adding a "revocation identifier" to the signature header could prevent
most of the avenues for abuse.
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.
Rather than taking a finger-print of the message as described in 9.4.1,
establishing persistent revocation identifiers would offer opportunities
to prevent this threat.
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
Reputation must be based only upon authenticated identifiers, which
underscores limitations establishing assurances for specific
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.
There would be a desire to leave signed messages unaltered to avoid
incurring a reputation risk.
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)
Associating a mailbox with the signature, desirable from the standpoint
of anti-forgery value, would require additional standardization.
Perhaps flipping the Sender header with the Resent-Sender would allow
consistent tracking compatible with existing processing.
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).
The value of the information would be limited to the trustworthiness of
the signer. I doubt the recipient should see this information.
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.
Agreed. And we need to consider whether, given its blemishes, MASS is
adding value nonetheless.
Rather than scaling the signature to a domain-user resolution,
establishing a revocation identifier could establish significant value
to justify the use of a domain-wide signature.
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.
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.
Replay must be allowed until abuse has been reported or detected. An
optional revocation identifier would allow both protection of the
signature reputation, and provide a means to detect when abuse may be