[messaging] Upcoming design changes in Viol^W Flute!

[George Kadianakis]

Greetings,

starting with a small announcement: the project you knew (?) as Viola was
*renamed* to Flute. The original thread for this project was:
          https://moderncrypto.org/mail-archive/messaging/2016/002181.html

Flute is a secure multiparty messaging protocol. You can find the Flute
codebase here: https://github.com/asn-the-goblin-slayer/flute

And here is some history about the last 3 weeks of Flute development:

Development of Flute has been ongoing in a slow-but-steady sideproject-ish
manner. Fortunately, a few brave early adopters approached and are helping with
testing and patches. Lots of work remains to be done. See the github issues
page for some of the stuff that needs to be done.

If you are interested in helping or discussing Flute, you can join the #flute
channel at IRC server irc.baconsvin.org/6697. You don't need flute to talk in
that channel. We also have #flute_test as a flute-only channel: see the flute
README for more details. FWIW, setting up Flute should take about 7 mins for
someone on a modern Linux distro.

And here are some code/design improvements we did the past weeks:

- Implement periodic rekeying of rooms even if no one joins or leaves, to
  maintain forward secrecy.
- We now cache old keys for some time, to work around race conditions stemming
  from non-order-preserving chat frameworks like IRC.
- Addressed replay attacks on KEY_TRANSPORT packets using a monotonic
  counter. Need to do the same for ROOM_JOIN and ROOM_MESSAGE.
- Fixed various bugs found during testing
- Added a HACKING file for people who want to start contributing.

And here are some design/security issues high on my TODO list:

[Here is the protocol spec for those following from home:
https://github.com/asn-the-goblin-slayer/flute/blob/master/flute_spec.txt ]

[*] How does Alice learn the list of room members in a flute room?

  Currently, only the captain knows who are all the room members in a flute
  room, because it's the captain that performs the key transport protocol. The
  way the KEY_TRANSPORT protocol works, non-captain members only learn whether
  they were included in the room, and the max number of participants.

  I consider this to be a major UX issue of flute and I'd like to fix it ASAP.
  Here are some approaches to fix this (currently leaning towards the third one):

  * Every user who got the KEY_TRANSPORT packet sends a JOINED packet
    back. Everyone collects JOINED packets, and populates their room view.

    Cons of this idea:
       - Members can choose not to send JOINED packet.
       - Server can drop JOINED packets. 

  * The captain, for every key that is included in the KEY_TRANSPORT packet,
    also includes the ROOM_JOIN packet of that particular room member. The
    ROOM_JOIN packet is signed by that member's identity key, so the captain
    cannot fake it. We might want to add some sort of timestamp as well.

    Cons of this idea:
      - Not sure how this design would work _exactly_.
      - Timestamps are flaky.
      - KEY_TRANSPORT packets become much bigger.

  * The captain, for every room member included in the KEY_TRANSPORT packet,
    also includes the IRC nickname and/or the Flute identity key of that room
    member. This way, every room member has an immediate view of the whole room.

    The good thing about this idea, is that it's straightforward to implement
    and also to understand. That's why this idea is appealing to me.

    Of course, in this idea the captain can lie and include nicknames without
    actually including a valid key. Alternatively, the captain can completely
    omit members from the KEY_TRANSPORT packet.

    Fortunately, both of the above "attacks" are somewhat detectable. The first
    one can be detected by the offended party, and the second one can be
    detected by the whole group. Of course, the big question is what to do when
    an attack is detected?

[*] Replay attacks

  Replay attacks can be quite deadly in flute. If the protocol had no replay
  protection at all, an attacker (e.g. the IRC server) could replay old
  KEY_TRANSPORT packets and then replay old ROOM_MESSAGE packets, essentially
  rolling everyone to old keys and replaying old messages.

  For this attack to work, the KEY_TRANSPORT packet must be from the same room
  session as the current one (because members need to have the same room
  ephemeral key to be able to parse the KEY_TRANSPORT packet). Still it's an
  annoying attack because it's so easily performed by the server, or by
  non-members lurking in the IRC channel.

  To defend against the above attack, we added replay protection counters on
  KEY_TRANSPORT packets. When Alice receives a KEY_TRANSPORT packet, she
  records the current counter value, and only accepts KEY_TRANSPORT packets
  with strictly greater counter values. This way we get some sort of
  KEY_TRANSPORT replay protection.

  My plan is to add the same counter-based protection for ROOM_MESSAGE packets
  as well. And maybe add timestamp + local info (nick, server, channel) data in
  ROOM_JOIN packets to make those harder to replay as well.

Any feedback on these issues is welcome :)

After these issues get addressed, I plan to work more on the UX side. The
current UX is not totally awful, but it's definitely not pretty either.
Unfortunately, weechat is a command-line IRC client with some annoying
restrictions (no raw_input()), which makes UX improvements even harder.

Until next time!