[Mailman-Users] Preserving S/MIME-Encoded Mail

[Stephen J. Turnbull]

Grant Taylor writes:

 > I'll agree with you on Mailman's responsibility.  However in 10+ years 
 > of computer work I can assure you that there is quite a bit of software 
 > out there that /claims/ to do something but falls short of that claim.  ;)

Sure.  Why Mailman *should* make up for other software's deficiencies,
when it has (like all other software) enough trouble keeping its own
promises is the question.  Especially in something as difficult as
security.

 > > The user should put in an RFE for your MUA if that extra effort
 > > bothers him.  If he hasn't validated the signature himself, he
 > > has to assume that it is invalid.  This is not a task that can be
 > > delegated to mailing list software.
 > 
 > RFE?

Request For Enhancement.

 > I also don't understand how this task (technically) can not be 
 > delegated to the mailing list software.

Mailman is written in Python, Python is Turing complete, therefore any
computation can be delegated to Mailman in a technical sense. :-)

However, in security you assume that (a) the bad guys are indeed out
to get you, and (b) that everybody except you is a bad guy until
proven otherwise.  That includes mailing lists.  I see no reason why
mailing lists would be an exception to (a) or (b), so you don't want
to delegate trust if you can do the authentication yourself, which you
can.

 > > Please, no.  That's an open invitation to phishing.  To prevent it 
 > > robustly, Mailman would have to remove signatures that it can't 
 > > validate, otherwise a message could be crafted to look like one that 
 > > was validated by Mailman.  But that is clearly the wrong thing to do, 
 > > as the recipient might be able to validate signatures that Mailman 
 > > cannot.
 > 
 > I fail to see how this is an open invitation to phishing.

Given that the recipient is capable of doing anything Mailman can,
Mailman should not invite delegation of trust unless it can promise to
do what the recipient wants.  If trust is delegated, then there are
several avenues for phishing for those recipients who chose to trust
authentication by Mailman rather than doing itself, including but not
limited to spoofing Mailman-validated messages and suborning the
Mailman server.  Why spend effort on worrying about those things when
S/MIME is designed for end-to-end security anyway?

 > Further I fail to see how Mailman (presuming it had access to
 > OpenSSL's tool set) would not be able to validate standard S/MIME
 > signatures.  As S/MIME signatures are validated all the time by
 > MUAs that had no prior knowledge of the public key of the sender.

Oops, I probably should be saying "authentication" rather than
"validation".

The point is that as a guarantee of identity S/MIME signatures
ultimately depend on a certification authority.  It is quite possible
that you and I are members of an organization with reason to trust
that organization's self-certification, while we are communicating
via a third-party list.  Whether this is a relevant use-case, I can't
say, "yes" *or "no"*.  Why spend the effort to prove "no" when the
recipient should be doing the verification themselves anyway?

 > Encryption on the other hand requires prior knowledge.  Thus I
 > believe that it is possible for a mail handling program to take any
 > S/MIME signed message and test the signed message to make sure that
 > it was not altered.

Not since it was signed.  But what if the question is "who signed it?"

 > If you are worried about someone spoofing messages that Mailman would 
 > send, that should be simple to solve by having Mailman S/MIME sign its 
 > signatures.  In my head this means that you now have verification that 
 > what Mailman sent was 1) not modified and 2) was indeed sent by Mailman. 

Yes, but who cares whether Mailman in particular modified it or sent
it?  What you usually want is to know that it wasn't modified anywhere
by anyone, and that it was originally sent by the purported author.