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

Reply via email to