[messaging] Double Ratchet spec

[Nadim Kobeissi]

Dear Moxie,
Thank you for your substantial, considerate and valuable response.

Independent and open approaches to secure messaging implementation will
benefit greatly from the decisions taken by Open Whisper Systems to not
file for patents, to publish all their code under an open source license,
and to place all specifications in the public domain. This is admirable
behaviour that sets a higher standard for the rest of the security industry.

Given that Open Whisper Systems takes the term "Signal Protocol" to
include, also, multiparty functionality, multidevice functionality,
authentication functionality and media transfer functionality, it is
sensible and correct that the protocol is being published as a set of
modular components.

It also makes sense that Open Whisper Systems would need to further invest
a significant amount of time and experience in order to understand how to
document these other elements and new features.

That being said, a recommendation I would present is for Open Whisper
Systems to publish a skeleton of the full Signal Protocol, as in, a
high-level "map" of all the modules, as soon as possible. This could look
something like this (and this is potentially inaccurate draft example):

XEdDSA and VXEdDSA  --> X3DH --> Double Ratchet --> Media Transfer
                          |            |
                          |            |--> Multi-Party
                          v            |
                    Authentication     v
                                  Multi-Device

Let me explain why this "skeleton" of the full Signal Protocol is crucial
and high-priority: by publishing it, Open Whisper Systems will allow
researchers and independent implementers the chance to understand,
empirically and for the first time, what consists the full Signal Protocol.
This will allow researchers spending considerable time analyzing the Signal
Protocol to understand exactly which subset, or which specific region of
the protocol they are applying their analysis to. It will allow independent
implementers the chance to understand which aspects of the secure messaging
experience they would obtain by following the published specifications, and
which aspects would be left to their own devices submitting to their
individual constraints.

Importantly, this will also benefit Open Whisper Systems itself by allowing
it to commit to, and better illustrate, what it considers to be the
high-level view of the Signal Protocol.

So long as this map does not exist, the abstract notion of "The Signal
Protocol" will remain afflicted by an unfortunate level of ambiguity.
Publishing this skeleton is not a difficult task. A nice thing would be to
actually have that map on whispersystems.org/docs so that visitors can
click on parts of the map and be redirected to the relevant specification.

Regarding the Signal trademark: It seems reasonable as a business practice
for Open Whisper Systems to wield "Signal" as a reputable brand name and to
thus base a licensing program on it. I imagine the transaction would be
that Open Whisper Systems would provide some notion of "quality control"
for "Signal"-branded apps in exchange for licensing fees. An example of a
similar strategy could be the "Trump" brand, where "Trump Tower" buildings
are created independently, but can purchase the rights for the "Trump"
brand after getting in touch with the Trump organization, and thus become
"Trump Tower Istanbul." (I don't mean to compare Signal to the Trump
Organization, it simply provided a clear example for a branding-based
business strategy.) Especially in terms of the Android and iOS code, I
personally support the notion that Signal software truly enjoys an
exceptionally high level of care and quality, and basing a branding
strategy on this is well earned and well deserved.

While this is surely a sensible business practice when related to the
Signal software or brand, it seems to be an undesirable choice to also
apply that business logic to the protocol itself. This is because it would
somewhat go against the notion that these protocol components are being
published in the public domain for the sake of reproducibility across the
Internet. In reality, the problem here is that Open Whisper Systems chose a
name for The Signal Protocol that is too tied to their brand. A more
generic name should have been chosen. For example, imagine if TLS were
called The Google Protocol or The Netscape Protocol! Thankfully, "Transport
Layer Security Protocol" is more generic and therefore the protocol name
can be used without roping a protocol implementor into a branding and
trademark considerations that might in all innocence be completely
irrelevant to them.

For this reason, should they find my reasoning worthy of further
consideration, I recommend that Open Whisper Systems consider renaming The
Signal Protocol to a more generic name that is not tied to a trademark that
is being, nevertheless legitimately, licensed under a commercial branding
strategy.

I have attempted to present my perspective with self-awareness and with all
the consideration I could muster for the time you've taken to answer my
earlier questions. I hope that you can find a productive underpinning to
the discussion I make above.

I thank Moxie, Trevor and their teammates at Open Whisper Systems for their
work and for their time.

Regards,
Nadim



On Wed, Nov 30, 2016 at 4:22 AM, Moxie Marlinspike <moxie at thoughtcrime.org>
wrote:

>
> If there are any lingering IP questions around these documents:
>
> 1) Open Whisper Systems has not filed for any patents.
>
> 2) All Open Whisper Systems code is available under an open source license.
>
> 3) All of our specifications are placed in the public domain.
>
> 4) Open Whisper Systems welcomes third-party use of the terminology
> we've used in these documents.
>
> Regarding the documents we published and the full Signal Protocol:
>
> As we previously stated, Signal Protocol includes multiparty,
> multidevice, media, and authentication features built on top of the
> elements we've recently documented.  Signal Protocol is also a moving
> target; we're continuing to make enhancements for new use cases and new
> security features, and will continue doing so for the foreseeable
> future.  Once we've gotten more experience managing the documents we've
> published thus far, we'll consider how to document these higher-level
> elements and new features.
>
> We've made an effort to release standalone documents in order to make
> these concepts easier to reuse by different projects with different
> environments and constraints, and to avoid confusion between projects
> using Signal-like mechanisms and the full Signal Protocol.
>
> Regarding use of the names "Signal" and "Signal Protocol":
>
> These documents provide the flexibility projects with different
> constraints might need to implement something that works for them, so
> there is a fair amount of leeway in terms of how they're used as well as
> how they're combined and built upon.  As a result, our preference is
> that when people use what we've documented to construct their own
> protocols, such creations use an independent name.
>
> For example, the SlickSecure Mesenger might use a protocol called
> "Slick," and describe it as "Slick uses X3DH[ref] with such and such
> encoding and such and such key types in such and such way. The output is
> used to construct a Double Ratchet[ref] session in such and such way,
> etc..."
>
> We want to maintain "Signal" and "Signal Protocol" as names associated
> with up-to-date high-quality software, the latest protocol features, and
> all the specific choices that we've made in implementing these concepts.
>  We've made those choices very carefully, we will continue to update
> them carefully, and we want people to have confidence they will benefit
> from that care when they see the word "Signal."
>
> The Signal trademark allow us to ensure that remains true; we hope to
> develop a trademark licensing program in the near future, similar to
> what the Linux Foundation does with Linux.  In the meantime, definitely
> get in touch if you want to use the name "Signal" to represent your app.
>
> Thanks,
>
> - moxie
>
> On 11/20/2016 01:18 PM, Trevor Perrin wrote:
> > Hi all,
> >
> > A spec for the "Double Ratchet" algorithm is available at [1].
> >
> > We'd welcome feedback, as usual.
> >
> > Trevor
> >
> > [1] https://whispersystems.org/docs/
> > _______________________________________________
> > Messaging mailing list
> > Messaging at moderncrypto.org
> > https://moderncrypto.org/mailman/listinfo/messaging
> >
>
> --
> http://www.thoughtcrime.org
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20161130/8d54ab60/attachment.html>