Open mmccool opened 3 years ago
This case is when multiple TDDs are returning TD for the same Thing, but the TDs are in conflict. In this case one of the TDDs may be a "spoofer" attempting a man-in-the-middle attack (or just stale, or just in error) and should be ignored. Note that in cases of multiple TDDs returning different TDs the results should be merged. There are valid cases where TDs change (eg moving from manufactured to operational state, updating IP addresses, rotating keys, etc) and if there are multiple TDDs they could become temporarily out of sync (stale TDs) but this should not be misinterpreted as an attack. We might need some kind of multi-phase commit process for things like IP address changes. For example, it might be best to invalidate all old TDs before adding new ones. It might be possible to use time-stamps but these are currently optional in TDs, so either we need to add them (and update proof chains) or use out-of-band information on update times. Not convinced time-stamps completely solve the attack problem since an attacker can just pick a more recent time.
Also discussed here: https://github.com/w3c/wot-thing-description/issues/977
We have this use-case in the RIOT OS implementation sooner than later. When a user setups a device, this device only gets a link-local address. When the setup is done and the device is connected to the router, it may only get a ULA for a certain amount of time. Maybe even forever, if the user doesn't configure it differently. And maybe eventually a global IP address. Configurable IP addresses may be a topic for us as well.
Don't see how we can resolve this in the time we have. Defer to next version...
Add trustability, response time, etc., as possible evaluation features of TDDs for advanced directory services. Issue is that if we have multiple possible directories that are returning conflicting information, how to chose one of them. See TPAC minutes and comment from @ashimura