Re: Device Discovery and Telehash

<<< 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.
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.


<<< 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.

<<< 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.

<<< 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.

Regards,
Tibor





On Tue, Feb 9, 2016 at 2:33 PM, Carsten Bormann <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?
>