On 29.09.22 18:53, Christian Huitema wrote:
On 9/28/2022 12:06 AM, Eliot Lear wrote:Hi Christian, just following up on this:And following up myself. I am looking at the deltas between draft 10 and draft 9, and while it goes in the right direction, I would love to see a bit more work to address my main points:1) It would be nice to have some structure in the security section, delineating the different attacks that we are worried about. But that's a nice to have, and I will soon stop asking for that.2) I am not concerned about the disclosure of software vulnerabilities per software versions, but I am still concerned about the inventory of devices. Especially if there is an easy way to query devices and find what software version they are running. Attackers are going to love an automated way to find out which devices run what vulnerable version.
This is a model, not an access method. The access methods can apply access control to this information, and I think this is to be expected. But how that happens will vary by circumstance, and is up to vendors to decide. Expect a lot of OAUTHiness IMHO.
3) Of course, in managed networks, defenders can also use the inventory of devices running vulnerable versions to shore up defenses, so there is clearly a trade-off. But that trade-off does not happen in networks that are not managed, especially networks in which devices may be plugged in more or less in their default configuration. The attackers can get the data, and there are no defenders to use it. The discussion with Elliot and Michael concluded with Michael's suggestion that the inventory functions should be disabled by default, and should only be enabled after devices are properly onboarded. That recomendation is not found in draft-10.
No, I don't think that was the conclusion, nor do I agree with it. Again, this is a model. There's no mechanism to disable. The objects will be present in whatever mechanisms use the model, and the issue you are raising, which I still don't really agree with, should be addressed there. We go into some detail to describe what can be a threat, and that those making use of this model MAY authenticate the information. See below about that MAY.
4) Draft-10 introduces a kind of typo. The sentence "These are the subtrees and data nodes and their sensitivity/vulnerability:" was moved from the paragraph starting "There are a number of data nodes" to the paragraph starting "Some of the readable data nodes". Or I guess that was the intent, because the sentence was left at one position and copied at the other. Easy fix.
Ok.
5) The sentence about "some network environments" was not removed, but merely moved a few paragraphs down. That sentence includes no less than three qualifiers to minimize the potential threat: "some data nodes" (how many? just a few?), "may be considered sensitive" (but perhaps the authors doubt it?), "in some network environments" (which ones? just a few?). I would really like to read something more direct.
Ah - it occurred in two places and I removed one. There was writing and now there is reading. Here there is a difference. There are indeed some environments, particularly industrial ones that are intended to be entirely disconnected where the security model is evolving. That is, today there are places where encryption simply isn't used. That will change over time, but only very slowly, and this information will be of the least value to an attacker, compared to what else is available.
Eliot
OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
