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

[Stephen J. Turnbull]

Daniel Kahn Gillmor writes:

 > The only way that a DKIM check would fail for the given attack, would be
 > if the DKIM included the To: and Cc: headers and the list was configured
 > to reject mail that either (a) failed or did not have a DKIM signature,
 > or (b) did not include the list's address in either To: or Cc:.  Is that
 > what you're suggesting?

Yes.  Validating anything about a given message is a PITA, as you
know.  I think this is the best we can do with the MTA-level headers
(by MTA-level I mean they might be augmented or reordered by MTAs, so
we would need a DKIM-like algorithm to sign the header in the MUA
anyway).

FYI: In Mailman REJECT is a technical term that implies a notification
to sender.  In context, I assume you meant "reject, discard, or
[maybe] hold".

 > > 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.
 > 
 > the point of the scenario is to think clearly about the relationship
 > between key expiry and message/signature validity, which are distinct
 > but associated things.

AFAIK key expiry is associated with signing, not with validation.
Associating key expiry with validation would mean you basically can't
use expirable keys with mail, and especially not with archived mail.

 > doing decent key management is tricky.

Sure, but this particular case is well-defined AFAIK.  It's out of our
hands.

 > >  > > 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 
 > 
 > i tend to agree with you here; but it looks like you might have gotten
 > cut off.  did you have more to say on this question?

I usually do ;-) but often enough it's sufficient unimportant that I
forget.  I'm not sure what I intended to say. :-/  Possibly a
reference to the idea of encapsulating the whole intended message
(especially the "originator headers" per RFC 5322) in a signed part to
avoid the whole "can we trust the headers" issue.  In this format the
important headers would be signed, so we trust them as much as we
trust the signature.

 > > 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.
 > 
 > I think doing proper key management is a lot trickier than that.

Of course it is.  I'm saying it's not in scope, not for this GSoC
proposal for sure, and probably not for Mailman.

 > both X.509 PKI and OpenPGP "Web of Trust"-style authentication
 > networks have a lot of fiddly bits and ways to get the
 > implementation wrong *and* controls that you might or might not
 > want to expose to the end user.

I wonder why they're so fiddly? ;-)  And why we should think we can do
better?

If you're an avatar of djb or Bruce Schneier, say so, and I'll take
your word for it.  I *know* I don't know enough to make
recommendations here, let alone reify them in software.  I'm almost
certain Barry, Wacky, Terri, Florian, and Mark don't.  Nor Abhilash.

 > And for any key management regime:
 > 
 >  * what do you do with a message that is signed by a key that claims to
 > belong to party X but you can't verify the key identity?

Depends on list policy.  Default: HOLD.  (I'd like to say REJECT, but
you don't know you're not creating backscatter in that case.)  DISCARD
is a more or less plausible alternative, but I haven't thought about
it carefully.

 >  * Are all kinds of key identity verification failures the same, or
 >    are some different than others?  (e.g. do you handle messages
 >    signed by expired keys different from messages from messages
 >    signed by revoked keys?)

I would say, "not quite, not very, and no" for those two cases.  I'm
not sure this needs an option: both express the sender's intention
that the key not be used in this way.  There might be options about
how to handle it (eg, I suspect that in both cases the most common
reason for receiving such a message is pilot error by the sender, but
it needs confirmation -- so REJECT; there are arguments for DISCARD or
HOLD, though).

 > There are probably more questions for each domain, and more general
 > questions as well.  how many of the these decisions do you want to
 > expose to the list administrator?  how many do you want to expose to the
 > mailman installation operator?

These general questions are use-case-dependent, and therefore the
answer now is "none of them" for the list admin, and "all of them" for
the instance admin (who in general will be the same at this point in
history).  As use cases arise, we can revise the design.

 > how do you choose good defaults for these choices?

"Fail secure".

 > What does it mean (socially) to have an open-subscription list that
 > requires signatures from posters?

I don't know, and personally I don't really care.  I'm more interested
in open-subscription lists that require signatures on admin messages.

I conjecture that it could be useful on anonymized lists to prevent
spoofing members who have built up trust in their nicknames over time.

I guess this use case might require leaving the poster's signature in
place.

 > I suspect this could be solved by requiring subscription messages and
 > the like to have a standard format that explicitly includes the
 > globally-unique name of the list within the signed body, so that they
 > could not be replayed.

Didn't I suggest that?  I intended to.  More forgetfulness....

Steve