Hacker News new | past | comments | ask | show | jobs | submit login

I have read all the TLS WG discussions I can find on this RFC. The picture that emerges for me is that of an inherent, institutional failure in the nature of working groups.

As far as I can tell, there was only one person that raised the "we don't need this" objection (Nikos Mavrogiannopoulos, GnuTLS principal author). He asked for a defense of the feature on three occasions [0] [1], and received a response twice, both responses from the same person. There was no further discussion, so either his objection was addressed or he felt further discussion would be unproductive. I would be interested to know which. GnuTLS does ship with heartbeat disabled, so it's possible Nikos continued to express skepticism about the feature.

However this document was eyeballed by many security experts, who I will not name and shame here, who proofread or made comments or edits to the document, without objecting to the general premise.

It seems to me that, inherent in the nature of a working group, the specific parties who are in favor of the feature will always be better represented than the interests of a wider audience that faces the nonspecific harm that the feature might be implemented poorly and introduce a security vulnerability. Sort of a reverse-NIMBY situation if you like. The software community cannot mobilize to combat every new TLS proposal on the grounds of nonspecific harm, but everybody with a pet feature can mobilize to make sure it is standardized.

[0] http://ietf.10.n7.nabble.com/tsv-dir-review-of-draft-ietf-tl...

[1] http://ietf.10.n7.nabble.com/Working-group-last-call-for-dra...

Bear in mind, the feature itself isn't insecure. The experts who OK'd the feature failed to police an unstated and controversial norm for the group (that it should default to "no" answers). It's hard to fault people for that. I agree: the problem is the IETF process.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact