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 _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9