<div dir="ltr">broadly speaking, believing that a communication is secure/valid changes the behavior of communicating participants vs if communication is not secure. this is how most social engineering security issues come to pass.<div>

<br></div><div>for matters of security, being conversative about possible risks is a responsible strategy.</div><div><br></div><div>That said, if some folks comfortable with security and the like could do some white hat auditing/hammering on hs-tls, I think that would be the *ideal* way to help get buy in to that proposed approach. (not sure if such volunteers exist, but that would be the ideal scenario). I could ask 1-2 folks i know if they have any suggestions. </div>

<div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 4, 2013 at 1:24 AM, Vincent Hanquez <span dir="ltr"><<a href="mailto:tab@snarc.org" target="_blank">tab@snarc.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 2013-11-03 17:48, Scott Lawrence wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One could argue that the potential for a false sense of security could make (very) bad encryption worse than no encryption.<br>
<br>
</blockquote></div>
Well. No, false sense of security is bad, however is has no link with your absolute level of security.<br>
<br>
Even bad cryptographic implementation provide some security in a sense, at worse by obscurity<br>
(which is very poor security, but not zero), and In the best case (of the bad) a rather hard problem<br>
for resource-less people.<br>
<br>
Now i'm not saying that bad implementations are OK, and certainly I hope that's not the case in tls,<br>
but in the context where we got nothing, just as John Wiegley rightfully mentioned, the risk is<br>
quite small.<br>
<br>
it's rather sad to see the "i'ld rather have *no* security whatsoever, than maybe have some" hard line.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Personally, I've always been a bit uncomfortable with the small number of widely-used implementations (AFAIK OpenSSL and GnuTLS combined account for pretty much all TLS-using open-source software), and I think pushing another one into wider usage would be a good thing (while acknowledging that it's likely more vulnerable than the older implementations).<br>


<br>
</blockquote>
<br></div>
That, and also that half of openssl CVE in the past 20 years were buffer overflow/underflow.<br>
Nothing to do with cryptography, but rather just simple memory management.<br>
I think this got to give some security points for a (mostly) haskell implementation.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Vincent</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br></div>