[Mono-bugs] [Bug 78075][Nor] Changed - Mono SSL stack performance/tuning issues

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by sebastien at ximian.com.

http://bugzilla.ximian.com/show_bug.cgi?id=78075

--- shadow/78075	2006-04-12 18:04:54.000000000 -0400
+++ shadow/78075.tmp.1577	2006-04-12 20:51:36.000000000 -0400
@@ -311,6 +311,40 @@
 
 If we're not going to optimise the implementation sufficently (and i
 realise that fast crypto is hard, but it's somewhat critical to modern
 network applications, and who writes an app that isn't network aware
 these days?) we should really at least add the possibility of removing
 it from the list.
+
+------- Additional Comments From sebastien at ximian.com  2006-04-12 20:51 -------
+Well that's why I used quotes on "best". This is real life, not a
+cipher contest, and there is a context to consider before stamping
+"best" to anything (and I avoided "good enough" on purpose ;-). So
+let's the quoted best be interpreted as "best use of the available
+resources", otherwise "best" would be a synonym of "safe-n-easy" (yep,
+that's quoted too ;-).
+
+That "best" is always application/data specific, which is something
+pretty hard to set under a normal (i.e. generic) web server so we fall
+back on "safe-n-easy". However it's much easier (or at least possible)
+to select one for an application server.
+
+The second statement is correct but out of context. We're not talking
+about a (or some) suboptimal cipher(s). In fact most people didn't
+knew what was currently being used (and I still don't know about the
+ZMD 6.6.2 cipher being used and compared to). This is a purely, with a
+fit description, a speed issue.
+
+In this case I think it's clear the added security of AES256 isn't
+worth the extra time required to download the data (so we strike out
+the "safe-n-easy" server-selected option). However I'm sure many
+people would prefer taking the extra time to ensure the highest
+possible encryption (so removing AES, because it's too slow for
+applications dealing with large files, would be irresponsible). This
+boils down to choosing between an optimal (which I except the current
+ZMD 6.6.2, and possible others, algorithms to be) and a supra-optimal
+cipher (AES256) cipher.
+
+As for removing some ciphers from the list, we run into some problems.
+First the (MS designed) API being used doesn't allow providing extra
+information down to the SSL stack. Second, I still believe it's a
+server side decision and that the API should reflect that.