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.

for matters of security, being conversative about possible risks is a responsible strategy.

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. 




On Mon, Nov 4, 2013 at 1:24 AM, Vincent Hanquez <tab@snarc.org> wrote:
On 2013-11-03 17:48, Scott Lawrence wrote:
One could argue that the potential for a false sense of security could make (very) bad encryption worse than no encryption.

Well. No, false sense of security is bad, however is has no link with your absolute level of security.

Even bad cryptographic implementation provide some security in a sense, at worse by obscurity
(which is very poor security, but not zero), and In the best case (of the bad) a rather hard problem
for resource-less people.

Now i'm not saying that bad implementations are OK, and certainly I hope that's not the case in tls,
but in the context where we got nothing, just as John Wiegley rightfully mentioned, the risk is
quite small.

it's rather sad to see the "i'ld rather have *no* security whatsoever, than maybe have some" hard line.


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).


That, and also that half of openssl CVE in the past 20 years were buffer overflow/underflow.
Nothing to do with cryptography, but rather just simple memory management.
I think this got to give some security points for a (mostly) haskell implementation.

--
Vincent

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe