IMC Security mailing list

About

The mailing list is the place where discussions take place, thus it forms the very heart of the IMC Security working group.

While there has already been an Indymedia-related mailing list named "imc-security" hosted elsewhere in the past, the global IMC Security listserv is hosted on lists.indymedia.org.

Security

While IMC Security will discuss IT security related topics on this mailing list, the name of the listserv only relates to this topic, not to the setup of this list. By no means should you assume that this mailing list is technically more secure than any other mailing list hosted on lists.indymedia.org.

The list does however make use of the limited technical options the Mailman mailing list server provides for increasing security. By the time of writing, these were:

• Email sent to the list is not archived on lists.indymedia.org
• Email account confirmation and administrator approval are required to join the list

Additionally to these technical options, information security is provided by the web of trust.

Web of trust

If you use GnuPG (GPG) or its commercial pendant, you may already have heard about the 'web of trust'. If you have not come across this term before, please check its definition at Wikipedia, the look at its implementation in GnuPG at Cryptnet.net and the sketches outlining several webs of trust at ChaosReigns.com.

As some of the topics discussed by IMC Security are sensitive, we need to enforce a certain level of security by trustabilty within the working group. This is done by building and maintaining a web of trust. As we are not currently enforcing the use of GPG, we need to maintain this web of trust manually. This is done on the working groups' mailing list and maintained by the list admins by means of the mailing list policies (see below).

While our trust model is rather simple, there has been scientific research on trust based user groups which may be of interest to other Indymedia working groups which intend to form such a group, too.

• Trust-based Security in Web Services (master thesis); Platzer, Christian; Vienna, May 2nd 2004
• Please add any other documents you are aware of.

Policies

The list policies will help us to maintain the web of trust described above.

While these policies may seem complicated in the first place, we believe that they are a practicable way to upkeep an imc-security mailing list which is build on trust. Nevertheless, the list policies are imperfect and need to be discussed and improved. Anybody is invited to do so either on the list itself or on imc-tech.

Subscription

If there are less than 15 list current subscribers, the number of neccessary ACK / NACK, where it is >=2 in the above schemeS, is decreased to >=1. The current amount of list subscribers can be obtained from the list admins anytime. However, as a rule of thumb, you can expect it t be >= 15.

IF ( someone requests subscription through the form at http://lists.indymedia.org/imc-security ) {
  IF ( subscriber didn't send roll call ) {
    admins ask for roll call and  - if available - names of request supporters;
  }
  IF ( roll call is not received within a week after subscription request ) {
    subscription request is rejected;
    EXIT;
  }
  ELSE { // if roll call is received within a week
    IF ( roll call states that s/he is an 'Indymedia sysadmin as defined by IMC Security' [1] ) {
      IF ( roll call does not contain the host name of the server the requestor is Indymedia sysadmin for ) {
        admin asks for this information;
        IF ( host name of the server the requestor is Indymedia sysadmin for is not received within a week after reminder was sent ) {
          subscription request is rejected;
          requestor and mailing list are informed and the reason is given;
          EXIT;
        }
      }
      ELSE { // roll call contains the host name of the server the requestor is Indymedia sysadmin for
        admin sends an email to the root account of the previously provided IP or hostname of the server the requestor is Indymedia sysadmin for and a CC to the mailing list, the email contains a unique (preferrably random) number, word or sentence and a request to forward it to the imc-security mailing list;
        IF ( (email cannot be delivered for a week) OR (email is not replied upon for a week) ) {
          subscription request is rejected;
          requestor and mailing list are informed and the reason is given;
        }
        ELSE { // subscription requestor has forwarded the email to imc-security
          IF ( unique code in forwarded email does NOT match the one initially sent ) {
            subscription request is rejected;
            subscription requestor is banned from making urther subscription requests for six months;
            requestor and mailing list are informed and the reason is given;
          }
          ELSE { // unique code in forwarded email DOES match the one initially sent
            subscription request is approved;
            requestor and mailing list are informed;
          }
        }
      }
    }
    ELSE { // common non-sysadmin subscription request
      IF ( requestor can provide subscription supporters [2] of her/his request ) {
        admin adds a note to roll call asking the supporters [2] to confirm their support;
      }
      admin adds request for ACK/NACK to roll call;
      admin passes roll call & request for ACK/NACK to mailing list;
      IF ( >= 2 ACK within a week ) {
        IF ( >= 2 NACK within a week ) {
          subscription request is rejected with reason "Too many blocks";
          EXIT;
        }
        ELSE { // 0 or 1 NACK within a week
          admin approves subscription request;
          admin informs mailing list subscribers and requestor on the approval;
          EXIT;
        }
      }
    }
  }
}

[1] Indymeda sysadmin:
People who administrate (i.e. are root on) a server which host at least one IMC which has passed the new-imc process can join the imc-security list without being vouched, if, by receiving and acting upon an email sent to the root account on this server they can prove it.

[2] Subscription supporters:
People who state their trust in a subscription requestor. Of course, their support must be confirmed by themselves, other than that anybody could claim to be supported by someone who never even heard about her/him.

Unsubscription

IF ( a subscriber raises concerns about the trustability of another subscriber ) {
  IF ( person who raised concerns provides no reason ) {
    admins ask for reason;
  }
  IF ( person who raised concerns provides no reason within a week after concerns were raised ) {
    unsubscription request is is rejected;
    EXIT;
  }
  ELSE { // if person who raised concerns provides reasons within a week after concerns were raised
    list admins ask for ACK / NOACK;
    IF ( >= 2 ACK within a week ) {
      subscription in question is suspended - subscriber will temporarily not receive email passed through the mailing list;
      IF ( >= 2 NACK within a week ) {
        unsubscription request is rejected;
        END;
      }
      ELSE { // 0 or 1 NACK within a week
        unsubscription request is approved;
        admins unsubscribe list member;
        END;
      }
    }
  }
}

Discussion

Known problems caused by the list policy

There are a couple of major problems with the current approach.

1. The people who are currently subscribed to the mailing list are the only ones allowed to vouch, even though their own trustability has not always been proven by means of this system. There is no way to overcome this problem completey, as using this system will always need an initial trusted group. However, to make sure everyone on this list is really trusted by enough people, it would be possible to restart this group with only two initial group members whom trust each other.

Not a complete solution, but an intermediary and besides this pretty trust-assuring method would be to regularly, about once or twice a year, ask all current list subscribers - including list admins - to provide vouches for all other subscribers. After that, whoever has not received two vouches within a week (or two), is considered untrusted will face forceful unsubscription.

II. Subscription requestors do not know who is currently subscribed to the mailing list and thus cannot ask them to vouch for them.

To overcome this problem, we do it the other way around: the subscribers are asked to vouch for any subscription requestors. List subscription requests are forwarded to the list, and the current subscribers need to make statements on whether or not they know and/or trust (both!) this person. This, on the other hand, means that this mailing list can and will only work with an active user base, but in the end, that's the case for all mailing lists.

III. People from abroad may not get sufficient vouches as they know too few of the people who are already subscribed.

The Indymedia sysadmin subscription policy extension was introduced to address this problem. However, this is only a partial fix. On the other hand, the exclusion of people who are not known to the other people of this working group, is a logical succession and may at a certain point be considered a neccessary method of protection for the information available to the working group. In other words: in real life, too, you would not trust someone you do not know, even if s/he states to work for Indymedia. The only way to overcome this problem is, to meet, in real life, as many Indymedia activists engaged within IMC Security as possible.

-- AlsteR - 24 Jun 2005