<div dir="ltr"><div>Dear Moxie,</div><div>Thank you for your substantial, considerate and valuable response.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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):</div><div><br></div><div>XEdDSA and VXEdDSA --> X3DH --> Double Ratchet --> Media Transfer</div><div> | |</div><div> | |--> Multi-Party</div><div> v |</div><div> Authentication v</div><div> Multi-Device</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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 <a href="http://whispersystems.org/docs">whispersystems.org/docs</a> so that visitors can click on parts of the map and be redirected to the relevant specification.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I thank Moxie, Trevor and their teammates at Open Whisper Systems for their work and for their time.</div><div><br></div><div>Regards,</div><div>Nadim</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 30, 2016 at 4:22 AM, Moxie Marlinspike <span dir="ltr"><<a href="mailto:moxie@thoughtcrime.org" target="_blank">moxie@thoughtcrime.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br> If there are any lingering IP questions around these documents:<br> <br> 1) Open Whisper Systems has not filed for any patents.<br> <br> 2) All Open Whisper Systems code is available under an open source license.<br> <br> 3) All of our specifications are placed in the public domain.<br> <br> 4) Open Whisper Systems welcomes third-party use of the terminology<br> we've used in these documents.<br> <br> Regarding the documents we published and the full Signal Protocol:<br> <br> As we previously stated, Signal Protocol includes multiparty,<br> multidevice, media, and authentication features built on top of the<br> elements we've recently documented. Signal Protocol is also a moving<br> target; we're continuing to make enhancements for new use cases and new<br> security features, and will continue doing so for the foreseeable<br> future. Once we've gotten more experience managing the documents we've<br> published thus far, we'll consider how to document these higher-level<br> elements and new features.<br> <br> We've made an effort to release standalone documents in order to make<br> these concepts easier to reuse by different projects with different<br> environments and constraints, and to avoid confusion between projects<br> using Signal-like mechanisms and the full Signal Protocol.<br> <br> Regarding use of the names "Signal" and "Signal Protocol":<br> <br> These documents provide the flexibility projects with different<br> constraints might need to implement something that works for them, so<br> there is a fair amount of leeway in terms of how they're used as well as<br> how they're combined and built upon. As a result, our preference is<br> that when people use what we've documented to construct their own<br> protocols, such creations use an independent name.<br> <br> For example, the SlickSecure Mesenger might use a protocol called<br> "Slick," and describe it as "Slick uses X3DH[ref] with such and such<br> encoding and such and such key types in such and such way. The output is<br> used to construct a Double Ratchet[ref] session in such and such way,<br> etc..."<br> <br> We want to maintain "Signal" and "Signal Protocol" as names associated<br> with up-to-date high-quality software, the latest protocol features, and<br> all the specific choices that we've made in implementing these concepts.<br> We've made those choices very carefully, we will continue to update<br> them carefully, and we want people to have confidence they will benefit<br> from that care when they see the word "Signal."<br> <br> The Signal trademark allow us to ensure that remains true; we hope to<br> develop a trademark licensing program in the near future, similar to<br> what the Linux Foundation does with Linux. In the meantime, definitely<br> get in touch if you want to use the name "Signal" to represent your app.<br> <br> Thanks,<br> <br> - moxie<br> <div class="HOEnZb"><div class="h5"><br> On 11/20/2016 01:18 PM, Trevor Perrin wrote:<br> > Hi all,<br> ><br> > A spec for the "Double Ratchet" algorithm is available at [1].<br> ><br> > We'd welcome feedback, as usual.<br> ><br> > Trevor<br> ><br> > [1] <a href="https://whispersystems.org/docs/" rel="noreferrer" target="_blank">https://whispersystems.org/<wbr>docs/</a><br> > ______________________________<wbr>_________________<br> > Messaging mailing list<br> > <a href="mailto:Messaging@moderncrypto.org">Messaging@moderncrypto.org</a><br> > <a href="https://moderncrypto.org/mailman/listinfo/messaging" rel="noreferrer" target="_blank">https://moderncrypto.org/<wbr>mailman/listinfo/messaging</a><br> ><br> <br> </div></div><span class="HOEnZb"><font color="#888888">--<br> <a href="http://www.thoughtcrime.org" rel="noreferrer" target="_blank">http://www.thoughtcrime.org</a><br> </font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br> Messaging mailing list<br> <a href="mailto:Messaging@moderncrypto.org">Messaging@moderncrypto.org</a><br> <a href="https://moderncrypto.org/mailman/listinfo/messaging" rel="noreferrer" target="_blank">https://moderncrypto.org/<wbr>mailman/listinfo/messaging</a><br> </div></div></blockquote></div><br></div>