On Mon, Oct 26, 2020 at 06:42:21PM +0100, Toerless Eckert wrote: > Thanks, Jared > > Somehow everybody tries to escape answering the question asked by giving > their correct but orthogonal pet problem space answer. Ted correctly claims > the protocols suck security wise, and you correctly claim that there are a > lot more > deployment considerations in face of risky underlays. > > At this point in time i am just trying to get an RFC out the door, and Bens > security review was asking for options how to operationalize the choosen > protocol > to be hardened. My answer was the heuristic. > > If the anwer of the experts is "do not harden implementations of existing > protocols", > but only improve protocols or eliminate security risks from underlays, i think > that is not a good strategy to show to implementors trying to understand how > to best harden existing protocols, but i will happily take that guidance > and remove the text about the suggested heuristics.
I think we often forget several things about the security aspects of devices, like physical access == root (for example), on-link or on-network attackers will always have an advantage available to them. Things like mDNS are only as secure as their local link, and if an attacker is on-link there are risks that can be controlled for and those that can't. We have had problems elsewhere as md5/tcp-md5 provide engouh mutual peer authentication to be of value, but can be broken with a persistent on-link or on-path attacker. I was also just providing examples of other protocols (dhcp, ra) that share the same on-link risks. - Jared -- Jared Mauch | pgp key available via finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop