"Michael" == Michael Thomas <mike(_at_)mtcc(_dot_)com> writes:
Michael> On Thu, 2005-02-10 at 16:53 -0500, Sam Hartman wrote:
>> >>>>> "John" == John R Levine <johnl(_at_)iecc(_dot_)com> writes:
>>
John> This is the Project Lumos fallacy. I have no interest
John> whatsoever in distinguishing between a domain's nice users
John> and its nasty users. I believe that each domain is
John> responsible for keeping its users in line, and the reason
John> that signatures are useful is to help me alert domains about
John> undesirable mail they've sent. If they send a lot of
John> undesirable mail, I'm going to reject the whole domain, not
John> do their filtering for them.
>> As discussed in section 4.1 of Russ's draft, a domain cannot
>> know how widely a message will be distributed. Once I have a
>> signed copy of that message I can choose to distribute it much
>> more widely than the sending domain might like me to do.
Michael> That's true _regardless_ of whether there's a signature
Michael> there or not. That's why characterizing this as a replay
Michael> attack fundamentally misses the point about mail
Michael> distribution: with SMTP, that's a feature not a bug.
It's an attack that prevents you from building up useful reputation
data about a significant class of domain.
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.
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.
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.
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.
--Sam