[OTR-dev] OTR version 4 Draft

[Nik Unger]

On 12/13/2016 06:25 PM, Rosalie Tolentino wrote:
> I am Rosalie from the STRIKE team at Thoughtworks, and I'd like to
> present a draft of OTR version four: https://github.com/twstrike/otrv4

Hello everyone,

I took a look at the proposed specification earlier this month.
Independent of the naming of this initiative (as discussed in the other
reply thread), I have a few comments on the specification itself. I've
also incorporated some comments from Ian on the first few sections.

Before jumping into more detailed points, I'd like to raise a broader
issue that merits discussion: what should the purpose of "OTRv4" be? Is
our goal to update OTRv3 so that we get more modern cryptographic
primitives and better deniability properties for instant messaging over
XMPP, or is our goal to design a protocol that provides a competitive
alternative to protocols like Signal in newer messaging environments?
The best design decisions depend on the objective.

If the goal of this effort is to improve OTRv3, then I think that this
proposal provides an excellent foundation for discussion and iteration.
However, I also think that we should have a discussion about whether
this is the best objective. One of the reasons for Signal's success is
that the messaging landscape has changed substantially since OTRv3 was
designed; asynchronous communication networks are now one of the most
important environments. Moreover, Google's move away from XMPP has
decreased the importance of the protocol for mainstream users. For the
remaining XMPP market, the acceptance of OMEMO (Signal for XMPP) by the
XMPP Standards Foundation in December has cleared the way for Signal to
become the dominant secure messaging layer.

At the same time, criticisms of Open Whisper Systems' management of the
Signal protocol and app suggest that there is room for an alternative,
as long as it can compete in the same markets. This proposal does not
appear to have been designed to do that (e.g., due to a requirement for
synchronous communication, and compromises related to the need for
OTRv3-style session initiation). I would prefer to see a design that
provides an alternative to Signal. I would also like to see some
discussion about this design direction on this list.

With that out of the way, here's some of our specific comments on the
specification as written:
========================================================================

I'd like to point out some major design decisions for discussion on this
list. Justifications are given in the specification (particularly in the
"architecture-decisions" directory), but these choices are worth
highlighting:
- XSalsa20 is used instead of AES.
- 3072-bit DH is used to offer resistance against elliptic curve
weaknesses. There is no explicit attempt to provide forward secrecy
against quantum cryptanalysis.

Some high-level points that apply throughout the document:
- All group elements received from another party should be checked to
ensure that they are in the correct group and that they are not the
identity element. This is pointed out at one point in the document, but
not in other places where this check must be performed.
- For maximum usefulness, the document should be entirely
self-contained. Concepts referenced from the OTRv3 specification and
other documents should be included in the OTRv4 specification.
- When using abbreviations or ideas that are introduced later in the
specification, either include forward references, or move the
definitions before their first use.

One thing that I would like to see in any OTRv4 specification would be
explicit instructions for the production of forged transcripts, for the
benefit of deniability. Ideally, any library that implements an OTRv4
API should be able to produce forged transcripts using the same
functions that are used to conduct honest conversations, and this design
should be strongly encouraged and guided by the specification.

Concerning the choice of Spawn as the DAKE, we are hoping to publish an
updated scheme soon (certainly before any deployment of OTRv4). Although
we have some improvements to the design of Spawn and our other DAKEs,
the changes will not affect the specification too much. That said, Spawn
is the least efficient of the three DAKEs that we have described. Its
use here appears to be motivated by the synchronous network environment
and the need to send an OTR initiation request in the first message flow
(without the ability to include a ciphertext). The specification should
explicitly justify the use of this inferior DAKE in the design decision
documents. The constraint on the first flow comes from the need for the
underlying messaging platform to support insecure communication; this is
one of the reasons that I would like to see a discussion about the
objectives of OTRv4.

Specific points and questions about the specification as written (our
comments are preceded by asterisks):
- High Level Overview:
  - "An OTRv4 conversation is established when one participant requests
    a conversation"
    * This statement is misleading; the request does not itself
      establish the OTRv4 conversation.
- Assumptions:
  - "The network model provides in-order delivery of messages, but some
    messages may not be delivered."
    * Is in-order delivery a necessary assumption, given the use of the
      double ratchet? What about if an active attacker modifies the
      order?
- Security Properties:
  - "In an OTRv4 conversation, both sides can verify the identity of the
    other participant but cannot transfer this knowledge to a third
    party."
    * This is also misleading. The party to the conversation can of
      course transfer _knowledge_ (just by telling the person) but not
      _cryptographic proof_ (so the recipient has to just trust the
      party to the conversation).
  - "If key material has been compromised, previous messages are
    protected."
    * Except, as mentioned earlier, against quantum adversaries.
  - "In this case, future messages are protected in future ratchets
    only."
    * There are multiple ratchets; this statement only applies to the DH
      and ECDH ratchets.
  - "Both parties can deny that they have participated in a
    conversation. They can also deny having sent any of the exchanged
    messages in the conversation. The respective party can be certain of
    the authenticity of the messages but cannot transfer this knowledge
    to someone else."
    * Anybody can deny anything. These statements should be more
      specific as to what it means to be able to deny something. The
      last statement is redundant to the above (and should be tweaked in
      a similar way, or just removed to eliminate the redundancy).
- Elliptic Curve Parameters:
  * If you're giving all these other parameters, give the equation of
    the curve as well, and specifically point out whether you're working
    in Edwards coordinates or something else.
  - "encoded and decoded using the rules for MPIs"
    * Multi-Precision Integers have not been introduced yet. Include a
      forward reference and incorporate the definition from the OTRv3
      specification.
- 3072 Diffie-Hellman Parameters
  * The title should be "3072-bit Diffie-Hellman Parameters".
  * As for the elliptic curve parameters, you should specify the order
    of g, as well as the cofactor.  (The order is q = (p-1)/2, which is
    prime, and the cofactor is 2.)
  * If 3072-bit DH is being used for quantum resistance in addition to
    resistance against elliptic curve weaknesses, then this should be
    included in the architecture decisions file.
- Data Types
  * It would be better to include the elliptic curve point encoding
    right here in the document, instead of by reference.
  * That seems like a really nontrivial approach to removing the
    cofactor, instead of just multiplying by 4 at an appropriate place.
- DRE messages and Auth
  - "phi (DATA)"
    * phi is shared session state from the high-level protocol, and not
      a custom value included in a DRE ciphertext. In addition to any
      shared session state known by the implementer (who has complete
      knowledge of the application network stack), you should also
      included specific values in the definition of phi that are imposed
      by this specification.
- TLV Types
  * Again, don't reference another document. Say they're the same as
    OTRv3, but include them here as well. Additionally, define "TLV"
    within this document.
- OTR Error Messages
  * Can this functionality can be abused by an active attacker?
- Key Management
  * Why the term "mix key"? In previous discussions about OTRv4, this
    was called an "insurance key".
  * Those variables don't seem correct. The protocol retains the concept
    of acknowledging new DH and ECDH keys. Consequently, you need to
    keep track of at least two DH and two ECDH keypairs, because each
    message will publish its "next" key, but the sender will use its
    current key until it sees an acknowledgment from the receiver that
    it has received the "next" key.
  - "The previously mentioned variables are affected by these events":
    * How are they affected? Include explicit forward references to the
      places where this is discussed.
- Generating ECDH and DH keys
  - "return our_ecdh.public = G1 * r, our_ecdh.secret = r"
    * In the notation section above, you wrote scalar point
      multiplication as "a * B", so this should be "r * G1".  But G1 is
      the Cramer-Shoup generator; you surely want the ECDH generator B
      here, no?  So "r * B"?
* (We have not finished a careful reading beyond this point.)
- Shared secrets
  - "A SHA3-256 of"
    * Perhaps "A SHA3-256 hash of"
- User Profile
  - "Client implementation should determine the frequency of user's
    profile expiration and renewal."
    * Later on, you recommend a value of two weeks. Consider including
      that recommendation here as well (or move it here).
  - "Version (BYTE)"
    * Can a user profile support multiple versions?
  - "Profile Signature (MPI)"
    * Specify the message for this signature explicitly. The
      specification should unambiguously define what values are
      included, and in what order.
- Deniable Authenticated Key Exchange (DAKE) > Overview
  - "Prekey (psi_1)"
    * Since you are using Spawn interactively, it's misleading to refer
      to the first flow (psi_1) as a "prekey". That term implies
      non-interactive storage of multiple values by a central server, as
      in Signal.
- Deniable Authenticated Key Exchange (DAKE) > Bob (Part 4)
  - "(Y, B) in the message is a prekey that Bob previously sent and has
    not been used."
    * Since you are using Spawn interactively, it is also critical that
      Bob verifies that the prekey is the one that he sent to Alice in
      THIS session. Otherwise, you partially lose online deniability
      unnecessarily.
- Protocol events > Receiving plaintext with the whitespace tag
  - "Remove the whitespace tag and display the message to the user."
    * It's worth considering discarding the message here, and requiring
      the sender to re-send the message (or drop it) over the subsequent
      secure channel.
- Receiving a Pre-key message
  - "Verify that the DH public key B is from the correct group."
    * Also ensure that the key is not degenerate.
- Socialist Millionaires Protocol (SMP)
  - "To define the SMP values under Ed448, we reuse the previously
    defined generator for Cramer-Shoup"
    * Cramer-Shoup requires TWO distinct and unrelated generators.
      Specify that you are using G1 here.
  * It is important to check that the received elements are part of the
    correct group and that they are not degenerate.
- Considerations for networks which allow multiple devices
  * This should be "Considerations for networks THAT allow multiple
    devices".
- ROM Authentication > Domain parameters
  * Again, specify that you are using the G1 Cramer-Shoup generator.

Points for the architecture decisions documents:
- ADR 1: Security Level
  * Although the use of SHA3-512 as a MAC should be safe because the
    values used here are of fixed width, we should consider using KMAC,
    since it is part of a draft standard.

========================================================================
Ian will be attending the Tor meeting in Amsterdam, so perhaps Ola, he,
and any other interested parties could set aside some time to go over
the document (or an iterated version of it) in person there?

~Nik