[OTR-dev] OTR version 4 Draft

[Ola Bini]

Hi Nik, everyone,

Thanks to you and Ian for the review, thoughts and comments!

I would like to address your general comments in this email, and the
rest of the team will look over your specific comments and fix them or
ask questions about them in separate emails! =3D)

When it comes to the purpose of "OTRv4" - I don't actually think you
have to choose between your two alternatives. Our specification is in
no way tied to XMPP or any other messaging protocol.

Specifically, when it comes to things that make our "OTRv4" unsuitable
as a competitor for Signal, it is only out-of-order delivery and
offline messages that are missing.

When it comes to out-of-order delivery, we had first planned on
supporting that - but the consensus from the meeting at Tor dev end of
September in Seattle was that it was too large of a burden. Ian was
present at that meeting. But if that's something that should be
re-evaluated, we can definitely do that.

"OTRv4" doesn't explicitly contain support for offline session
initiation - but we have designed to protocol in such a way that it's
possible to build an offline protocol on top of it, without any
changes to "OTRv4". Our plan was to first get the online use cases
sorted out, and then create a separate smaller specification for
offline OTRv4. The reason for that is because of the complications
involved in requiring third-party servers and other aspects. But it's
been part of - and is - part of our plan for "OTRv4".

> compromises related to the need for OTRv3-style session initiation).=20
I'm not sure I understand what you mean with this. Can you elaborate?

> 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.
As mentioned above - we designed OTRv4 to allow for both online and
offline session initiation. We choose SPAWN, since that would allow us
better security properties in the online case - but we could still use
the same primitives and algorithms for the offline case.=20

>     * Is in-order delivery a necessary assumption, given the use of the
>       double ratchet? What about if an active attacker modifies the
>       order?
As currently written, order modification will have the same effect as
dropped packages.

> - Key Management
>   * Why the term "mix key"? In previous discussions about OTRv4, this
>     was called an "insurance key".
Actually, it has been called "super encryption" in all discussions I
was part of. I never heard it called an "insurance key", which is
completely fine. We ended up with "mix key" since it's a key that will
be mixed in with the rest of the material for the ratchet.

>   - "Version (BYTE)"
>     * Can a user profile support multiple versions?
Not as we currently wrote it, but that's something we should consider.

>     * 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.
We used the name "prekey" since we expect to use Spawn both
interactively and non-interactively, but that's certainly something ew
can change.

> 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?
Me, Iv=E1n and Yakira will all be attending the Tor meeting, so we
should be able to have a discussion there - but it would be great if
we could continue making progress here in the meantime too!

Cheers
-- 
 Ola Bini (https://olabini.se)

 "Yields falsehood when quined" yields falsehood when quined.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20170131/93876a1d/attachment.sig>