Then let me go ahead and re-frame this from my point of view. I work inside a NOC as a systems engineer. I do many things there, including cyber-security, maintenance, configuration management across 60k devices, planning, deployment, and systems programming. We evaluate all sorts of tools and systems to determine proper fitness of software. Obviously, because we are a NOC, we are tremendously conservative in our choices primarily because at least 60 networks are under our purview.

Let that color how I choose what I've said, and how I continue to state my opinions.

> I won’t say much about crypto at this point other than we plan on having FIPS-140-2 certified crypto in the near future.

We trust OpenSSL and OpenSSH, with appropriate recommendations on types of keys and length. We wouldn't care if they aren't FIPS-140-2, primarily because we don't trust NIST's minimum. We prefer to exceed it, regardless if they approve it or not. We take the common security/crypto mailing lists and take the best suggestions from them. In other words, listing FIPS-140-2 is more marketing speak than anything else... Primarily because you need strong layered security, and not just a single heavy crypto key.

> Yes, we are using a new protocol, but I don’t agree that it needs to be a full IETF standard. We are working within the standard IP 99 protocol. A protocol is just another piece of code, just like any other part of a systems code base. It just happens that this code talks to code on another machine. Should IETF or others review all code before using? Has all the code you use been so reviewed?

If you want me to consider running your code under a non-TCP, non-UDP, non-ICMP code, you better believe it.

Quite a while back, Target was hacked. Had a whole bunch of point of sale terminals hacked. Do you know how they were hacked? Their systems were secure, facing the outside world. But the HVAC system was not. And that HVAC system that ran their ventilation had a hole that a MACK truck could drive through. You're providing that hole that I know nothing about, can find little to nothing about, and really have no nothing. It is purely the theoretical "Black Box" that uses IP, and nothing else I can interrogate about.

I want to see your protocol. I want to understand how sending data works, and how receiving data works. Is it routable or not? Can it handle errors, or does it fail? I have only your word. That's not acceptable. If the protocol was available, then we could see how the data is structured. This shouldn't be obfuscated... but it is.

---------------------------------------------

> We don’t know if there is a protocol error in the definition of our stuff. If we did, we would fix it. What we did is a careful analysis and design of a highly constrained solution that was then carefully implemented and tested. That’s about as good as a human constructed machine can be built. If errors are found as the protocol is used, we will fix them, provided they are revealed to us. That’s the problem with cybersecurity, you never really know.

There are ways to run formal tests on code. It's hard, but you're coming into the picture of "We can handle your IoT and industrial machine code". And they, like a NOC, don't take hand-wavey brushes aside casually. Do you know what happens if you tell a Siemann's motor controller to spin faster? It spins faster. Know what happens if it is told to go even faster? It breaks and catches fire. With a known, well documented, and proven protocol, we can know the failure domains. Instead, I'm told that some rando pentesters couldn't find anything. Inexcusable.

And you mentioned "Human tested". As you should know, there's plenty of ways to run "non-human testing". Fuzzers are a great low-ball way of finding errors in code. So are linters. And since you're using IP, how does your code handle Fragrouter? I'd be a betting man and say, "Not very well". An Open Protocol design would catch many, many of these. But you eschew that for proprietariness sake. And if the link to the person who hacked hard drive controller chips didn't prove to you your black-box methodology is faulty, I have no clue what would.

------------------------------------------

> You need a peer review of a protocol. OK, but I ask again, does all your code need such a review before you will use it? Or are you singling out network protocols? BTW we are considering making this an open standard for the language and the wireline protocol, but we need to see how this plays out first.

Yes, I am singling out network protocols. Very much so. I get if you have a application-internal API to talk to another application (Layer 5 over established layer 4 domain). Yeah, that's annoying, but I can firewall and segregate it and treat it as the dumb black-box it is. But once you jump down to Layer 4 code, you damn straight I want to understand its ramifications, its failure domains, and generally what to expect from it. Tl;Dr. I don't like surprises, and I really like RFC's to fall back on.

You provide me with surprises, and little/no documentation. No RFC's. Completely unknown Layer 4 code.


------------------------------------------

> Respectfully, I stand behind my statement that a system can’t be proven secure. I understand that there is a lot of good work going on in provably correct systems using formal methods. And I think that they will help greatly in making systems more correct, but they will never ultimately prove correctness in the mathematical sense. Take the Erlang code, how do you know it’s design is correct? That is, maybe it does exactly the wrong thing. Or that the code testing the Erlang code is correct?

In a way, I agree and disagree with you.

We run Apache a great deal for all our infrastructure with Web server demands. Have we personally reviewed Apache? Nope. Millions of people before us have. And the code is available if we need to. And millions of people have ran it, and provided feedback, suggestions, and bugfixes to the codebase. Even though we personally have reviewed it, the possibility is there for us to do so. And given our needs, we can safely say that our implementations of Apache are safe and secure.

We've also developed our own API. It's a complicated API. One of the tools we designed was a tracer for each of our calls, to trace how a call mutates through our stack for proper behavior. In fact, we can prove what our code is doing each step of the way, to its resolution. It's not a black box "we think we kinda know but not for sure", but we can say "this is what our code is doing, 100% guaranteed". We can thank the complete transparency of Linux of being able to track everything. MS Windows people can't say that. They can only black-box test, because they don't know how the system actually works.

I can keep beating the drum, but the underlying protocol should not only be well understood, but provable OR battle tested over thousands of people. Since your protocol is for pay, then the only way for you to go is formally proved. Yes, it's bloody hard. But you're getting into an area that without formal proof, will demand that the code is battle tested. And I'm seeing neither. No, some skiddies you hired don't count.

---------------------------------------------

> Yes, there is a chance that our product will get hacked. But, that is not the issue. The issue is: will that take more effort, time, money, and resources to do than for what is being used today? We think the answer is yes.

Seriously, this is your defense??? Hang out for a bit on 4chan, or on some of the Onion IRC's. There's lots of reasons to hack. I did so because I was curious. I know others who do it for "The Lulz". They have infinite amount of time, no regard for money, and only care as a trophy. The Black hats, well, you wont even know you were hacked unless you pay someone on a Onion auction site for the details.

---------------------------------------------

> MQTT is a good example. The payload can be anything, including malware, as in the example where a client gets compromised. Our protocol is highly restricted so that secretly passing malware in a message is highly unlikely.

That's marketer-speak. Means nothing, unless you have a formula that can scan every binary blob for all malware, in the past, present, and future. And guess what, I don't believe that you do..

---------------------------------------------

> Overall, we believe that our product is simpler and less error prone to configure, and less vulnerable to exploits then assembling all the technologies that have been mentioned here. We are providing just one piece of a cybersecurity framework that only covers controls network communications, as part of an overall cybersecurity plan.

Again, I've asked for citations of the data structures, reference implementation, and other basic requirements. Ive been consistently dismissed with hand-wavey "Pentester", "Black box", and "Security tested" justifications with no substantive proof of said security. To put it bluntly, I'd be embarrassed to even mention your proposed super-secret protocol to even control a coffee-maker. Primarily, because I don't know what ramifications I'd be allowing on our network if I did possibly say "Maybe" or "Yes". I can't, and wouldn't risk it.

Ive also played with, and am using experimental network code. I use IPFS quite a bit. I've also pioneered in using Tor with IoT communications and control systems. To put it bluntly, I'm well familiar with how these types of communications work and fail. And I'm not seeing a strong future with your proposed solution, given the closed nature you adhere to. My open protocol, open source solutions work better than some random "magically better" closed source solution. And I'm not susceptible to lockin. I would be with yours... if ever any devices would work with it.

Ive given you my criticisms. If you choose to dismiss it, so be it. I know some find my words to be fallacious or harsh. But you came to HN to show it off. These are my words in response to your project. Ive had similar on some of my projects. I try to be constructive, but sometimes destructive is better. To get better perspective of my viewpoint, look no further than http://hackaday.com/2014/11/18/thalmic-labs-shuts-down-free-developer-access/ (Ive moved from GitHub to Gitlab, BTW).