Thanks, also for the link! Indeed, that paper (from your 'found it' link) is referenced from the paper I mentioned. But it doesn't seem to include some of their more important findings, and it also refutes some earlier "solutions". E.g. "Moreover the authors erroneously recommend to use a 2-byte counter for DevNonce instead of a pseudo-random value, and to increment the counter only when a (valid) Join Accept message is received. According to the authors the latter ensures that the DevNonce counter is shared by the device and the NS. Firstly this is wrong since it is possible to replay any Join Accept message. Secondly this recommendation leads to a simple attack which allows to disconnect the device from the network once and for all."
I understand I can check the source myself (although I'm not completely sure the TTN backend is already fully open sourced - I haven't looked into that), but since security issues can be quite subtle, it could easily take a day or two to prove all these potential issues to be fixed, and I'd rather hear a simple "yes we're aware and it's not an issue for this and this reason".. This would be much more reassuring for anyone interested. In your first post, you said they "won't exactly tell the public which countermeasures are implemented". Are you involved in the TTN organisation or are you just guessing?
I was just trying to say, maybe poorly phrased, that I think most users of the TTN network probably care more about knowing that certain issues were fixed, rather than how many other papers discuss said issues. If any.
I'm not sure what you're implying here , or which of my previous posts would have given you this idea. I'm simply interested in making sure TTN is secure. I don't have a second agenda, and I don't work for (or have any connection to) a competitor. TTN seems like a great initiative! A few months ago I did some tests with a self made node, porting the IBM library to work on STM32. It worked great and was a lot of fun.