[Mailman-Developers] OpenPGP Mailman integration discussion [was: Re: GSoc - Requirement from Mentor to complete the project]

[Stephen J. Turnbull]

Abhilash Raj writes:

 > This part is little difficult to ponder on. Suppose a user signs up
 > for a list. He creates a user account and subscribes to a particular
 > list which needs his pub-key and implements signing.

In Mailman 3, users and subscriptions are separate concepts.  We
should assume that users and subscriptions are both authenticated,
potentially separately.  I think that to start with, we can assume
that the user key will be used for all user configuration
(subscription, etc), and for posting.

The second stage would be to allow a list to require a separate key
(subkey) for posting.

The third stage would be to require a separate key for administration
(user configuration).

 > If he signs up for a single list which does not require signing
 > then what? There will not be any key to sign administrative
 > requests.

For starters we'll simply require a separate installation for secure
and insecure lists.  The whole Mailman instance is secure and all
users must have user keys.

This is a proof-of-concept implementation; we think about weaker and
more complex security models later.

 > > sure, but the From: header is forgeable, right?  so if Alice knows
 > > that Bob was subscribed to list X in the past, and is subscribed to
 > > list Y today, then she could dig up his old posts in list X, and
 > > forward them (From: header intact!) directly to list Y.  Should
 > > list Y publish them?

Sure, but a secure list should be on a site using DKIM and this will
fail the DKIM check, I think.

Alternatively you can set up the list so that the whole post
(originator headers included) is sent as an attachment (a signed part
of a multipart message).  The list can then prepend the trace headers
(informational only, not authenticable) from the wrapper message when
it forwards the encapsulated message.  Outlook users will generally
not be able to do this, so it's another proof of concept. :-)

This is like a secure tunnel (eg, using SSH port forwarding).

 > No, I think if someone tries to send any of his previous message again
 > we can rebound it saying that the same message was posted before.

Sure, but identifying that requires secure headers.  See above.

 > Also the time-stamp from the message signature would indicate that the
 > message was indeed signed long time back and hence should be bounced
 > back without checking if it was a replay of an old message. Here a 'long
 > time' may be a cutoff set by the list owner which may default to one
 > week considering the delay in smtp delivery( which you mentioned to be
 > 4 days at maximum).

SMTP doesn't really work that way; there are no time guarantees (the
chain of forward can be arbitrarily long, and each one will retry for
up to 4 days in normal configurations).  Furthermore, I regularly see
spew from Windows boxes with mail written offline.  I think the
*principle* of using the signature's time-stamp is OK, but the cutoff
time should be determined by the list's sense of how long post content
can stay "hot".

 > A cutoff of one week should be sufficient to include the small time( at
 > max a day )

I've seen many cases where timestamp skew on authentic messages was
much greater than a day.  Again, this is a matter for list policy.

 > Is the timestamp in the OpenPGP signature not forgeable? Does it not
 > depend on the hardware clock of the system where the message was
 > signed?

It's forgeable, but only by the owner of the private key.  The
hardware clock could be deliberately skewed, but I can't see how that
would create a useful attack on a list.  (I guess you could imagine a
scenario with a "deadman switch" controlling a message that would be
sent if the creator doesn't cancel it, but that's a scenario for
Mission Impossible IV, I think.)

 > > (if < means "is earlier than": X < Y < Z)
 > > 
 > > X: message signature created (according to OpenPGP timestamp) Y:
 > > key expired Z: message received by mailman

I don't understand the point of this scenario.  X is a valid
signature, and there are known to be delays in delivery.  X should
just be treated as an old signature.

 > > yep, mailman generates messages of this form from PGP/MIME-signed 
 > > messages.  That said, mailman's generated messages aren't usually
 > > sent to mailman as input; maybe mailman shouldn't process these as
 > > signed messages?

Such messages can be generated in many ways; the fact that Mailman
does is just a proof of concept.

 > What is the structure of message with quoted text( when replying to a
 > mail inline )?

It's a flat body.  It has no MIME structure unless the user
deliberately creates it (well, in some cases attachments may be
automatically forwarded).

 > Are those signed by the user replying to it?

The interesting question is whether the quote is signed by the OP, and
the answer it that no, it can't be.  You could choose to send the
original signed body (with signature) for verification of the accuracy
of your quote, but the quote itself will be signed as part of the
reply by the replying agent.

 > Just out of curiosity is the forging of headers a trivial thing? Can I
 > send a message with some address not owned by me to say this very list
 > easily? (I don't want to though ,just asking if I can ;-)

Yes, all headers are easily forged unless the sending site uses DKIM.
The envelope data is also easily forged.

 > > 0) mailman could ignore all messages except those that are fully
 > > signed (this is probably the easiest)

I suspect that some people's legal disclaimer will fall outside the
signed text.  No can do.

 > > 1) mailman could strip off all outer layers until it finds an
 > > inner part that is itself fully signed, and then process that part
 > > as though it were the entire message

I think this is the right way to handle layered messages when
signatures are required.  The 

 > >>> This hand-waves around the difficult question: how do we know
 > >>> what the user's pub-key is?

I think we can punt on this.  "The same way we ever do."  Ie, we use a
PK certification infrastructure or a web of trust.  That's up to the
list owner.

 > > What happens if a list member revokes their key, or lets it expire?
 > > can that member upload a new one?

Not if they needed approval in the first place.  If the list is
open-subscription, yes, but a confirmation mail to the subscription
address and notification to list owner are required here.  I'm not
sure if it's possible to use a revoked or expired key in that state,
but if so it might be useful to use it "just that one more time".

 > > how does the list know that this key replacement is legitimate,
 > > and not being done by an adversary or an impersonator?

See above.

 > So in general terms if I import a key from a public keyserver, I
 > cannot be sure that the pub-key belongs to owner of the address the
 > key verifies?

No, you can't.  Anybody can upload such keys.  You need to either rely
on a certification authority, or the web of trust.

Note that Daniel already answered that question, in some detail, in
the post you were replying to.  If you don't understand the answer the
first time, reread the answer.  Then try to refine your question.
It's not just a matter of courtesy to someone who has spent a lot of
effort in crafting clear answers; you'll also learn a *lot* faster.

 > > Alice creates a phony mailman instance with a list Y that Bob
 > > *does* want to subscribe to;  Bob tries to sign up for list Y,
 > > expecting a challenge that he will sign and respond to.
 > > 
 > > When the request from Bob for List Y comes in, Alice spoofs a 
 > > subscription attempt "From: Bob" to list X, harvests list X's 
 > > (legitimate) challenge to Bob, and has List Y replay it to Bob as
 > > the challenge for List Y.  Bob signs the challenge, returns it to
 > > list Y (which is still operated secretly by Alice), and Alice in
 > > turn replays Bob's signed response to list X.

Probably this requires a version of the Diffie-Hellman handshake,
actually.

 > > One other question just occurred to me:  Once these features 
 > > (signed-messages-only) are implemented, hould existing 
 > > (non-OpenPGP-enabled) lists be able to be upgraded to use these
 > > new features?

As an authentication option for administrative mails, I don't see a
problem.  For post authentication, technically I don't see a great
difficulty in switching to "everything must be authenticated" (ie,
signed), but socially I think it's a mess.  Creation of a new list is
the right way to go.  That allows birectional gatewaying (with human
moderation insecure -> secure).  But this is way down on the priority
list.

Note that Mailman 2 will never get these capabilities, at least not
from the current team.