4 ms·

One thing that would limit feature creep would have the TLS WG maintain a POSIX reference library implementation, standard library compatibility interface (head

One thing that would limit feature creep would have the TLS WG maintain a POSIX reference library implementation, standard library compatibility interface (header file) and a comprehensive test suite. Because once the maintenance of that hits the people making suggestions and decisions, priorities will adjusted. (It still takes work to do the right thing regardless, but at least there would be a baseline, and behavior across implementations would be more comparable.) Also, accelerate the sunset of older specs so that deployed code will have to stay more current to even function, rather than interop'ing with old code that will never be patched.

tptacek 12y ago
I'm not so sure. Look at Heartbleed: the vulnerable reference code was committed by the person who wrote the Internet Draft.
- midas007 12y ago
  But then they would think twice before furthering "...serves too many interests, and (particularly in the TLS portion of the tree) is a grab bag of functionality" [0] of un-security-like features like heartbeats. They might think: "Do I really want to write tests and a demo for this, or can I make do with something simpler?" If not, then this suggests a lack of clear guiding principles of what is in-scope and what is not &| insufficient questioning of adding new features. [0] https://news.ycombinator.com/item?id=7566456 https://news.ycombinator.com/item?id=7566456
  - tptacek 12y ago
    I think that is a real problem, yes; I also think that problem is endemic to open standards groups.
    - midas007 12y ago
      But that's not an acceptable assessment of leadership for a vital crypto WG, much less the leading implementation. So far, OpenSSL has added one dev and it seems like business as usual. Does anyone know if anything's changed at TLS WG (I'm not on the mailing lists)? In other news, I ported LibreSSL to OSX today[0]. [0] https://github.com/steakknife/libressl https://github.com/steakknife/libressl
      - tptacek 12y ago
        I'm not sure what to tell you. I follow the mailing lists but very deliberately don't post on them, because I would drastically increase the noise level, which is already often bad. I can say that it does not look like the TLS WG has a "default deny" stance w/r/t/ new features for TLS. I like what Google is doing; they control the Internet's most important server properties and one of the most important clients, and are taking full advantage of that to testbed TLS refinements and then bring them to the IETF as working code.
        midas007 12y ago
        That's what I was after... confirmation that it's a Tragedy of the Commons. There's political ammo now to make necessary changes in how things are done to make sure OpenSSL, TLS WG doesn't continue with business-as-usual.

tptacek 12y ago

I'm not so sure. Look at Heartbleed: the vulnerable reference code was committed by the person who wrote the Internet Draft.

midas007 12y ago
But then they would think twice before furthering "...serves too many interests, and (particularly in the TLS portion of the tree) is a grab bag of functionality" [0] of un-security-like features like heartbeats. They might think: "Do I really want to write tests and a demo for this, or can I make do with something simpler?" If not, then this suggests a lack of clear guiding principles of what is in-scope and what is not &| insufficient questioning of adding new features. [0] https://news.ycombinator.com/item?id=7566456 https://news.ycombinator.com/item?id=7566456
- tptacek 12y ago
  I think that is a real problem, yes; I also think that problem is endemic to open standards groups.
  - midas007 12y ago
    But that's not an acceptable assessment of leadership for a vital crypto WG, much less the leading implementation. So far, OpenSSL has added one dev and it seems like business as usual. Does anyone know if anything's changed at TLS WG (I'm not on the mailing lists)? In other news, I ported LibreSSL to OSX today[0]. [0] https://github.com/steakknife/libressl https://github.com/steakknife/libressl
    - tptacek 12y ago
      I'm not sure what to tell you. I follow the mailing lists but very deliberately don't post on them, because I would drastically increase the noise level, which is already often bad. I can say that it does not look like the TLS WG has a "default deny" stance w/r/t/ new features for TLS. I like what Google is doing; they control the Internet's most important server properties and one of the most important clients, and are taking full advantage of that to testbed TLS refinements and then bring them to the IETF as working code.
      - midas007 12y ago
        That's what I was after... confirmation that it's a Tragedy of the Commons. There's political ammo now to make necessary changes in how things are done to make sure OpenSSL, TLS WG doesn't continue with business-as-usual.