<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Apr 5, 2016, at 8:00 PM, david wong <<a href="mailto:davidwong.crypto@gmail.com" class="">davidwong.crypto@gmail.com</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">WhatsApp just announced end-to-end encryption on their service, and the details show that they do not use TLS but another TLS-like protocol called Noise Pipes which was designed by one man.</span></div></blockquote></div><br class=""><div class=""><div class="">TLS is a very old protocol that needs to be put out to pasture so that</div><div class="">it can end its days peacefully after having worked so hard for more</div><div class="">than two decades. 2+ years ago we argued that </div><div class=""><a href="https://pomcor.com/whitepapers/TimeToRedesignTLS.pdf" class="">it is time to redesign transport layer security from scratch</a> taking</div><div class="">into account all the lessons that have been learned since SSL was</div><div class="">designed in 1994, instead of piling up new versions of TLS that make</div><div class="">things worse by increasing complexity. Then we proposed several</div><div class=""><a href="https://pomcor.com/techreports/M2MSec14.pdf" class="">protocol design patterns</a> that could be used in the design of a variety</div><div class="">of new protocols. (We proposed these patterns in the context of</div><div class="">machine-to-machine (M2M) communication, where different use cases may</div><div class="">call for different protocols; but one use case that we very much had</div><div class="">in mind when we wrote the paper was connection security for the world</div><div class="">wide web.)</div><div class=""><br class=""></div><div class="">I was not familiar with Noise Pipes. I've done a search and had a</div><div class="">very quick look at <a href="http://noiseprotocol.org/noise.html" class="">this</a>. I'm happy to see that there are some</div><div class="">commonalities with our M2M paper, including the idea of considering</div><div class="">the pros and cons of multiple patterns within a common framework.</div><div class="">(Our patterns, however, are *design* patterns for a family of possible</div><div class="">protocols; each possible protocol within the family would implement</div><div class="">only one pattern, minimizing code and striving for simplicity of</div><div class="">implementation.) Noise pipes seems primarily concerned with</div><div class="">application data protection, whereas we were primarily concerned with</div><div class="">the handshake; our paper includes a solution to the rogue-CA problem</div><div class="">of the TLS server PKI, inspired by DANE.</div><div class=""><br class=""></div><div class="">Francisco</div><div class=""><br class=""></div><div class=""><br class=""></div></div></body></html>