[OTR-dev] please remove me from this list

Carol Drews cbdrews at verizon.net
Thu Feb 16 10:11:30 EST 2017



-----Original Message-----
From: OTR-dev [mailto:otr-dev-bounces at lists.cypherpunks.ca] On Behalf Of otr-dev-request at lists.cypherpunks.ca
Sent: Tuesday, January 31, 2017 11:00 AM
To: otr-dev at lists.cypherpunks.ca
Subject: OTR-dev Digest, Vol 89, Issue 2

Send OTR-dev mailing list submissions to
	otr-dev at lists.cypherpunks.ca

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
or, via email, send a message with subject or body 'help' to
	otr-dev-request at lists.cypherpunks.ca

You can reach the person managing the list at
	otr-dev-owner at lists.cypherpunks.ca

When replying, please edit your Subject line so it is more specific than "Re: Contents of OTR-dev digest..."


Today's Topics:

   1. Re: OTR version 4 Draft (Ola Bini)


----------------------------------------------------------------------

Message: 1
Date: Tue, 31 Jan 2017 09:47:20 -0500
From: Ola Bini <list at olabini.se>
To: Nik Unger <otr at taintedbit.com>
Cc: otr-dev at lists.cypherpunks.ca
Subject: Re: [OTR-dev] OTR version 4 Draft
Message-ID: <20170131144720.GI27636 at hidden>
Content-Type: text/plain; charset="utf-8"

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-0001.sig>

------------------------------

Subject: Digest Footer

_______________________________________________
OTR-dev mailing list
OTR-dev at lists.cypherpunks.ca
http://lists.cypherpunks.ca/mailman/listinfo/otr-dev


------------------------------

End of OTR-dev Digest, Vol 89, Issue 2
**************************************



More information about the OTR-dev mailing list