Rebuilding trust in the Internet's building blocks

Merike Kaeo's keynote "Waking Up the Guards" at the FIRST 2019 conference (recording now available on YouTube) highlighted how attacks on the internet core no longer target a single service (naming, routing, signing) but move between these to achieve their hostile result. Defenders, too, need to consider the consequences of their implementation choices as a whole, to reduce to opportunities for bad things to happen "in the seams" of the Internet. Thus, for example, an attack on DNS that started by exploiting weaknesses in BGP routing needs to be mitigated through a combination of prefix filtering, Resource Public Key Infrastructure (RPKI) and DNS Security (DNSSec). Those may well be managed by different parts of the organisation, or even different organisations, which need to work together to ensure the individual tools are effective in combination. Default settings – which are often selected for ease of debate, rather than overall security – may not be the best choice.

Key building blocks to all these systems are hard-to-impersonate identity, integrity, confidentiality and audit but, again, their interactions need to be understood. Ensure they do actually complement one another, rather than introducing single points of failure. Encryption, in particular, needs to be deployed with care: over-use may add little to confidentiality, but severely limit auditability. If an operator cannot detect when their infrastructure has been compromised then there's little benefit in passing on confidential communications to an unknown and probably hostile destination. Identity typically depends on some kind of credentials, but the security aspects of their whole lifecycle – generation, distribution, storage, recovery, delegation/transfer, revocation and destruction – need to be understood to avoid introducing weakness.

Finally, although Merike limited this point to communications with managers, it seems to me that it may be more widely valuable. Don't talk in acronyms, as I have here (!), say what a protocol or service actually does. Even for technical people, once in a while talking about "ensuring authoritative answers come from the expected place" might highlight mismatched assumptions that would be hidden by simply repeating "DNSSec".