[OTR-dev] IFF meeting notes - OTRv4

[Ian Goldberg]

On Thu, Mar 17, 2016 at 03:57:31PM -0400, David Goulet wrote:
> Hi!
> 
> I realized I completely forgot to send the list the notes from the meeting we
> had in Valencia, Spain at the IFF (Internet Freedom Festival).
> 
> We've mostly discussed the OTR version 4 "design and specification".
> 
> Participants in the discussion were (nickname alphabetical order):
>     dgoulet, dkg, iang, infinity0, isis, olabini
> (if I forgot your name, very sorry don't hesitate to fix :)
> 
> They are not very complete notes but at least they can trigger discussions.
> Also, if some stuff is incorrect or it's incomplete, please complement or/and
> correct.
> 
> So here are some points for the new protocol that were discussed:
> 
> ---
> == OTRv4 ==
> 
> - Kill SHA1 with fire and use SHA3.
> 
> - Ratcheting: use axolotl
>   Ref: https://github.com/trevp/axolotl/wiki
> 
> - DAKE (Deniability AKE)
>   Ref: https://cs.uwaterloo.ca/~iang/pubs/dake-ccs15.pdf
>     - Proposal is being tested and written by Ian's student. O(weeks) before
>       seeing something.
>     - Free feature: offline message
> 
> - Have an unauthenticated encrypted channel at the very beginning of the data
>   exchange. Use curve25519. One of the reason is to never have a packet on the
>   network that ain't encrypted or a key exchange. Useful?

Actually, what we ended up with here is this:

Just to slightly hedge against elliptic curves being weaker than we
think, or even to quantum computers with hundreds but not thousands of
qubits, the whole OTRv4 protocol (which itself uses ECC such as
curve25519 or maybe one of the 400-ish-bit ones) is wrapped in a
2048-bit mod p Diffie-Hellman.  The outer layer is not explicitly
authenticated.

This is admittedly a bit hare-brained, and needs more thought.  How does
it interact with the various deniability portions of the protocol, for
example?

> - Algorithm agility is in the version protocol. Let's _NOT_ exchange ciphers
>   list.
> 
> - We agree that ECC is an acceptable choice.

Modulo the above.  And hopefully every language that currently supports
OTR can sensibly implement ECC.

> - No PQ for now, we'll rev. the version if we want it.
> 
> - Improve version rollback issues with v4.
>   (Unfortunately, I do not have the speficics on this one in the notes :S)

The trick with rollback is that you want to include both sides'
announcements of what versions they support in the key derivation.  But
in OTRv3, the version announcement is _optional_.  So v4 (which is not
fixing a security problem, so rollback to v3 or v2 isn't a huge issue)
should rectify this by mandating the version negotiation (and then
including it in the key derivation).  Then if there's a v5 (particularly
a security fix), you won't be able to roll back to v4 if both sides
actually do support v5.

> ---
> 
> The short term goal here is to write a specification using those decisions
> which can then be reviewed by the community and then start implementation.
> 
> Thanks!
> David

Thanks for taking notes!

   - Ian