Re: Proposed Proposed Statement on e-mail encryption at the IETF

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>Mail to public mailing lists can already be signed (like this one is). It'd be nice if mailman didn't MITM the signed content, so that the signature can be validated.

The last time I checked, Mailman is pretty good about wrapping MIME parts when it
adds a header or footer, so if you send multipart/signed, that will be part of
the resulting message.

I also found that the way MUAs treat partially signed mail ranges from
mediocre (Thunderbird) to bad (Outlook and Alpine) to nonexistent (all
of the usual web mail.)

But I have to ask, what problem are we trying to solve?  The issues
here are roughly the same as the ones that came up when we were
designing DKIM, and some people insisted that mailing lists had to
preserve DKIM signatures.  (This was before last year's DMARC fiasco.)

As far as I could tell, the threat model was that bad guys were
flooding lists with forged mail, list operators were asleep at the
switch and did nothing about it, so recipients had to do retroactive
spam filtering.  While everyone agreed this model was silly, nobody
could come up with anything else other than to insist that it was
obvious which to me, at least, it was and is not.

There is a fairly popular list manager called Sympa which can
apparently do end to end S/MIME.  Contributors can provide an S/MIME
key when they sign up, it can verify signatures on the way in and
derypt mail encrypted to the list's key, then re-encrypt mail to each
recipient's key.  I say apparently because it's in the code and the
manual, but I can't find anyone who actually uses it so I don't know
if it works.

I wouldn't suggest the IETF switch from Mailman to Sympa, but if
people are interested in some code sprintage, they might hack on
Mailman to provide a way for subscribers to register S/MIME and PGP
keys, check signatures on the way in and annotate the mail to say what
it found.  We already do DKIM signatures on the way out which should
be adequate to protect the annotations.  Then once we see how that
works, we might add features to reject or at least make insulting
comments on unsigned mail from people who've provided keys.

R's,
John





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]