Thiago Macieira wrote: > Indeed. The security team should figure out a way so that discovery can be > secured against eavesdropping.
We don't have a standard way to do this (at the CoAP level). Of course, if your network uses encryption, then you already have some protection. > If that is not possible, then at least the > reply should be secure. Either way, the client sending the discovery needs to > list which port number it's listening for DTLS unicast replies on. That doesn't work either: The DTLS endpoint is separate from the UDP endpoint the multicast was sent from -- the response wouldn't match the request. http://tools.ietf.org/html/rfc7252#section-9.1.2 You could use two-step discovery: Only expose a single discovery resource on a DTLS-secured discovery endpoint in the unsecured /.well-known/core; then do discovery on that via DTLS. The only thing you really expose is the IP address, and that is already visible in the packet. All this doesn't really answer the question where the keys for the DTLS connection would come from. If you are still doing discovery, you may not know the other guy well enough (and v.v.) to talk to them securely. (DCAF might help here.) Gr??e, Carsten
