[erik123]

In NDN, all data is signed by data producers and verified by the consumers, and the data name provides essential context for security.

Centralizing the concept of security in the network's architecture will create an intractable problem. Certain parties will still want to impose their desire to be able to eavesdrop on the data. Therefore, there cannot be any real security in such centralized design for security.

The in tempore non suspecto in which it was still possible to roll out security jokes such as SSL, is over now. Nowadays, 95% of the world population (and their governments) will refuse to adopt any centralized security design, because they do not trust it.

In my impression, the project is dead on arrival.

[jrapdx3]

I'm wondering how the proposed security model differs from current practices. What you've quoted doesn't seem different. After all, on the web today, data producers send a certificate which the client "verifies". At least the long list of "CA" names in my browser purports to be "verified" by an "authority".

Maybe the point you're making is exemplified by the news item concerning a security breach that was detected after going on for 13 years. (http://cybertinel.com/wp-content/uploads/2014/09/HARKONNEN-O...)

The part that got my attention was the criminals having fooled users into revealing passwords using certificates purchased from CAs (at a total cost of $150,000).

That seems to mean the current CA system is broken. It's not a big surprise that a centralized security concept is in NDN--Verisign is one of its main supporters.

[SudoNick]

I think this is the first time I've heard of NDN, and I've only spent a short while reading about it. My first impression is:

1) It involves addressing chunks of data rather than hosts that hold those chunks. Somewhat like using URLs at the network level. So instead of IP/HTTPS where the network learns of host communications without learning of specific data exchanges, NPN would reveal those specific data exchanges to the network.

2) The mandatory "signature, coupled with data publisher information, enables determination of data provenance..." aspect would cut both ways. For we would be data consumers in some contexts and data producers in other contexts.

I hope I read something to dispel my concern, but I worry about increased metadata exposures and reduced ability to achieve beneficial levels of privacy/anonymity.

[jasonwatkinspdx]

As usual, people ranting on HN without bothering to read what they're ranting about.

You're assuming centralization. All that's in the specs are slots for a locator and signature value. It's left up to the application to define trust semantics be it PKI, WoT or whatever.

http://named-data.net/doc/ndn-tlv/signature.html

[reilly3000]

That is why I'm of the mind that both canonical identity and permission need to be managed in a globally distributed fashion with blockchain. In order to facilitate the level of data transfer that would need to happen between devices to accommodate the distribution of global scale permission data, networking does need to change fundamentally.

I envision my fridge having a permission entry that neighbor can use my car tomorrow, and also that a person I will never meet has purchased a ticket for a flight to Argentina next week. That data is constantly being shared on a mesh network with my car and everybody else's I drive down the road next to, across all of my devices and those of every other participant. No government or corporation should be able to have the whole set of data, and none of it should be able to have a very long half-life.

The only way we can move forward to a truly connected version of the future is with trust, and the only way to have a truly trusted security model is to have it be globally distributed. NDN may or may not be the next version of networking to support it, but I'm rather confident that TCP/IP isn't going to be the way we get there.

[chrisbolt]

As much as I like the idea that all communications should be confidential, your response doesn't refute the original poster's point, which is that any architecture that is impervious to eavesdropping would not be adopted by parties who want to impose their desire to eavesdrop on it, which is (according to the original poster) 95% of the world population (and their governments). (citation needed)

[takeda]

No, the protocol does not impose central authority for data signing, it is up to the application to do this.

[jimmaswell]

In what way is SSL a "security joke"?

[tinco]

In the way that it's really easy to pressure certificate authorities into sharing their secrets.

[coldtea]

Since most servers were found to be vulverable to crazy simple attacks like that: http://en.wikipedia.org/wiki/Heartbleed or the Apple one: http://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto...

(and tons of others besides, plus crappy code in the most prevalent implementations used).

[noselasd]

And when someone implements new code dealing with security, such bugs are not possible ?

[acdha]

He's going to write it, so it'll be better than everything in the past and unicorns will fly by when you use it.

Hypothetical code is always better than the unpleasant kind we actually write…

[coldtea]

I hope fighting that strawman you built was fun, but I really don't know where the BS snark came from.

I didn't say new code will be flawless. Just that OpenSSL code is bad and insecure.

>Hypothetical code is always better than the unpleasant kind we actually write…

Well written code is always better than the crap that OpenSSL was (crap as admitted by most of security experts and groups working with it).

People who cannot tell between code with inevitable bugs and flaws and crappy code that just welcomes them in, don't really belong in the profession.

[acdha]

> I hope fighting that strawman you built was fun, but I really don't know where the BS snark came from.

The BS snark which started it was your still-unsupported assertion that “SSL is a security joke”.

> Well written code is always better than the crap that OpenSSL was (crap as admitted by most of security experts and groups working with it).

It's easy to criticize OpenSSL and, well, every other SSL library which has had problems. It's a lot harder to replace it and actual security experts have thus far chosen to overhaul OpenSSL rather than trying to replace it from scratch. I trust the judgment of the OpenBSD and Google security teams over your assertion that it's so easy to replace.