On Wed, 23 Apr 2014 20:39:48 +0200, Pascal J. Bourguignon wrote:
When a HeartbeatRequest message is received and sending a HeartbeatResponse is not prohibited as described elsewhere in this document, the receiver MUST send a corresponding HeartbeatResponse message carrying AN EXACT COPY OF THE PAYLOAD of the received HeartbeatRequest.
I didn't mean to dispute that CL is a safer language. My point is that, as an implementer, the above paragraph in an SSL protocol extension should raise red lights.
What is the function of the described behavior? Why would I want to echo back data in context of a keep alive? A: None. You don't want to do that.
My position on this is to refuse to implement it. If that means my implementation is useless in the context of other implementations, I need to implement a better standard. I'd go as far as saying this is a moral issue. When implementing a standard means building a weapon pointed at half the Internet, the implementer is responsible for the resulting threat.
I have made mixed experiences with this. So far I have implemented a few standards where this approach worked just fine (email client, web server). I could just omit the behavior I deemed unacceptable and refuse to handle those messages or send a "501 Not Implemented" respectively. And while both email and the HTTP standards bear tons of legacy baggage and can be tedious to implement, I refer to them as _good_ standards bodies, because they let you safely omit their questionable components.
A security guy reading the TLS standard on the other hand, WILL think that it was written by a malicious party, optimized for being impossible to implement in a safe way. And while it is easier to implement the TLS standard correctly in Lisp, I believe it should be simple and well- written enough to be able to implement it safely even in C.