Kris Pister writes: > > there would be no false sense of security > > Can we see a show of hands of all of the people on the list who > think that there is any sense of security from using a key that is > published in an RFC? No? No one?
And ask that same question from normal users installing termostats or other internet of things devices? Or the application writer who do verify that yes the security level of the incoming packet is 7 so it is encrypted and integrity protected, but without bothering to check which key it was encrypted with? Note, that the application writer most likely do not even know how the keys are identified in the 802.15.4 link, thus he would not even know what kind of checks to put to his application to be able to verify that the packet actually had proper protection. The MAC layer will not filter these out as we need to be able to receive those frames during normal operations thus receiving data frames used for device wanting to join with that key is completely valid case. How many people here will know how to from following information "SecurityLevel, KeyIdMode, KeySource, KeyIndex" whether that key is K1 or K2? So when you receive MCPS-DATA.indication those parameters should you pass it to application or drop it? And no, this is real question, can you tell me how do I separete the K1 and K2 in the application level? > Good. No one has a false sense of security. We all know that using a > well-known key provides no security. Which is not mentioned at all in the draft. The draft makes all kind of security claims and claims that all those claims are true for all types of keys defined in there, i.e. per-configured keys at nodes, shared keys among peers, or well-known keys. So there is already huge false sense of security present in the draft. -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
