On 05/26/2013 12:57 PM, Stephen J. Turnbull wrote: > > > 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.
If i understand it correctly, DKIM allows the recipient of a message to
verify that it came from the domain it claims to come from, and that the
body and a select set of headers have not been tampered with while the
message was in transit. Bob's e-mail could come from Bob's own domain,
which isn't necessarily the domain associated with the list.
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?
> 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. :-)
including well-vetted way to be able to cryptographically verify headers
that mailman wants to rely on would be great! I'm not sure that
wrap-signing a message/rfc822 part is the right way to achieve those
goals, though.
> > > (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.
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. doing decent key management is tricky.
> > > 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?
> > >>> 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.
I think doing proper key management is a lot trickier than that. 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.
For example, for X.509:
* how do you decide what set of CAs belongs in the trusted root
authority list?
* do you check CRLs in certificates? if so, how often?
* do you use OCSP?
* Which X.509v3 extensions do you require for message signatures from
which algorithms?
For example, for OpenPGP-style certification networks:
* which keys do you assign full ownertrust to?
* which keys do you assign marginal ownertrust to?
* how do you deal with certifications from multiple marginally-trusted
accounts?
* how often do you check keyservers for updates?
* do you honor embedded keyserver URLs?
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?
* 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?)
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? how do you choose good defaults for
these choices?
> > > 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".
What does it mean (socially) to have an open-subscription list that
requires signatures from posters?
> > > 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.
i'm not convinced that DH will solve this problem without an additional
identifying layer -- the problem is the anonymity of the end point
itself, which DH won't solve on its own.
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. There may be other solutions as well, though.
--dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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
