<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014-04-18 1:15 GMT+02:00 Arne Renkema-Padmos <span dir="ltr"><<a href="mailto:renkema.padmos@gmail.com" target="_blank">renkema.padmos@gmail.com</a>></span>:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Also, who is going to spend 3x the processing time just because their SSL library might be borked? Where do you stop? Three different SSL libraries, three different compression libraries, three different operating systems, three different processors, etcetera.</div>

</blockquote><div><br></div><div>Me! And this might indeed be a good validation tactic for other softwares too. CPU's are not feasible, who watches the watchmen? Same goes for hydra-softwares.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>However, it might be nice to keep the idea in mind when designing new protocols: How can we support redundancy through multiple outputs, and how do you deal with upgrades and evolution of the protocol. Additionally, it might be applicable when verifying existing implementations. Also, in some scenarios the investment of redundancy could be actually worth it. This is also related to the idea of defence in depth. Ideally you wouldn't want to just run 3 different SSL libraries, but also do something like e.g. layer an SSL VPN on top of IPSec.<br>

</div></blockquote><div><br></div><div>Yeah, I really don't want a double excessively complicated stack. I just want the mathematics that I trust, as purely as they can be, as robustly and simply as they can be. For me, running the same equation using two different approaches is a decent way to verify results, same goes for this.<br>

<br>I think SSL is too complicated though. Performance seems to be the mayor factor, and I don't think that's sane.</div></div><br><br></div></div>