Re: Device Discovery and Telehash

Comments inline!

On 9 Feb 2016, at 20:52, Tibor Pardi <tibor@zovolt.com<mailto:tibor@zovolt.com>> wrote:

<<< Now I'm confused -- I thought this was what RFC 7650 is doing? >>>

I am sorry for the confusion.

As for RFC 7650, yes that is what the RFC 7650 and RFC 6940 RELOAD propose as well. In my opinion there are multiple viable solutions for P2P device discovery. One of them is RFC 7650 together with the RFC 6940 RELOAD which use Chord, and I understand some prefer to use that standard base solution. Other one is Telehash which uses Kademlia and that was IBM's preferred solution. There are few other Chord and Pastry based overlaying network implementations as well. I have simplified the Telehash concept by using only the pieces which we need for device discovery, plus added the JWT, JWS parts plus ECC crypto to it for authentication.

I was looking at RFC 7650 and RFC 6940, but for me it was not an option. The problems were
a) RELOAD uses a centralised enrolment server and I thought such architecture would defy the whole purpose of decentralised, P2P device discovery.

Exactly, as I said RELOAD few things that might not be that suitable. The use of Chord, the way access control is specified, the way resources are structured in dictionaries, security overhead,... . However the concept of a Distributed RD is good IMO. I think it might be simpler to start from a DHT (Kademlia) and an RD, and work from there onwards.

b) I contribute to this project as a voluntary developer and the implementation of the 160 pages long RELOAD protocol plus the RFC 7650 was a too ambitious undertaking for me in the first phase of P2P development. I couldn't find any existing source code with regards to those protocols, so I thought in step one I should go with a simpler solution, and then later, once I have more time improve the solution. The W3C web-of-things-framework is modular, so it won't be an issue to integrate RFC 7650 and RFC 6940.

RELOAD has few implementations for the same reason, also they tend to be implemented by operators and the code is not released.


<<< I am thinking if you guys would be interested on discussing RFC7650? https://tools.ietf.org/html/rfc7650

I don’t have proper slides with me now, but I could make some. Bear in mind that the RFC was done in the context of P2PSIP and it is a bit old, it also has some quirks to adapt to RELOAD’s architecture. That is why I suggest making it much simpler by focusing on DHT+RD only. who knows, maybe even the PubSub Broker could benefit from such distribution? (https://tools.ietf.org/html/draft-koster-core-coap-pubsub-04)
>>>

Yes, absolutely. We should discuss it and once I have time I can look at it, alternatively of course any one else can develop the software. Your suggestion about the implementation without RELOAD makes the work more doable terms of time and resources.

Absolutely, RELOAD creates a huge overhead. Let's have some informal email or phone discussion first then.


<<< Tibor, I am not very familiar with JWT, but I am thinking of something simple for signing, just hashes that map to the identity of the peer storing the information. In RELOAD they used hashes of the self-signed/CA-signed certificates. I don’t know what could we use for this. >>>

I understand your concern with regards to JWT, but JWT doesn't add much complexity to the solution. It is just an ECC signature accompanied with the JWT fields. On the other hand the public key signature identifies the originator of the message and guaranties data integrity, and it seems there is a consensus within the security force of the Interest Group that JWT should be used. I tried to explain in my previous emails how the solution use ECDSA, ECDH and AES cryptography. Functionality wise some elements of ECDSA is equivalent with the CA-signed certificate, without of course the stamp of the CA and the current implementation doesn't handle certificate authority based certificates. I assume many business use case will require CA and then the handling of the CA-signed certificates will be integrated.
All current DHTs use the hash what you have mentioned, so if you think for some reason JWT is not an option, then the hash what you have mentioned would be fine too and such approach would require a little modification. I assume it would be a configuration settings to indicate to not use JWT but only hash.

I just don't know enough yet about JWT to have a strong opinion in favor or against it :) I need to read more documentation about it. If we need to chose something to begin with, self-signed certificates are usually the easiest. No need to hurry the decision though.


<<< For me this has been a bit of a side-topic to this day, so I would be happy to learn more on it. I am not sure when do you guys have the next meeting? >>>

Sometimes I attend the security meeting, the next is Thursday, perhaps we can talk about this then? I am not sure if we can hijack that meeting for this, on the other hand it would be great to hear Oliver's and Dave's opinion on P2P device discovery and security. Alternatively, please let me know whenever you are on a meeting and want to discuss this and I will try to attend that meeting.

Maybe the Discovery group would make more sense, but both are fine. I will send you my details maybe we can have a chat before that?

Thanks!!!


Regards,
Tibor





On Tue, Feb 9, 2016 at 2:33 PM, Carsten Bormann <cabo@tzi.org<mailto:cabo@tzi.org>> wrote:
Now I'm confused -- I thought this was what RFC 7650 is doing?

Grüße, Carsten


Jaime Jiménez wrote:
> Have you looked into making it work with standard discovery mechanisms
> like CoAP Resource Directory?
> For example by storing the entries of the RD into a DHT?