ietf-mailsig
[Top] [All Lists]

Re: MASS Security Review document

2005-02-10 17:49:37

On Thu, 2005-02-10 at 19:17 -0500, Sam Hartman wrote:
"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.

Actually, I'd call it an _insignificant_ class of domain because
the reputation that you can derive from, oh say, hotmail or aol
or y! is so, so very problematic: even if they are behaving badly,
who would dare blacklist them? (ok, there will be some ninnies, but
they're outliers). *Far* more interesting and significant are the
domains that are *not* very well known. This gives a big incentive
to do very good policing lest your reputation suffer... 

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.

Do PGP or S/MIME have "replay attacks"?

I really think that "replay" is extremely unhelpful since it implies
that at a fundamental level that SMTP has such a concept: it does 
not. Which isn't to say that there isn't an issue, just that
calling it a replay only serves mask the underlying issues. 

                Mike


<Prev in Thread] Current Thread [Next in Thread>