Secure messaging over unsecured transports by Ash at DEF CON 29

[The Dark Tangent]

Secure messaging over unsecured transports
Ash

Prerequisites for students?:
Students should have a good understanding of DNS, Docker, and the Python programming language. An understanding of how to configure DNSSEC with their DNS server/provider of choice is necessary, and a basic understanding of how PKI works (roots of trust and the use of public keys to secure the conveyance of public keys) will be beneficial.

Materials or Equipment students will need to bring to participate?:

• Hardware: Laptop with 4GB of RAM, 20GB hard drive space free after installing software prerequisites
• Software: Please arrive with git, Docker engine, and docker-compose already installed

Other:

• Attendees must have administrative access to a public DNS zone on a server which supports the TLSA record type. Many SaaS DNS services support this, and PowerDNS supports the record type as well. Configure this zone for DNSSEC before class.
• If for some reason you cannot configure DNSSEC for your zone, you must be able to host static content over HTTPS under your domain. For example: if you're bringing mydomain.example to the workshop, you must be able to host static content on a server at https://device.mydomain.example/. If you can't do DNSSEC, bring a web server.

What level of skill is required for your targeted audience?:
Intermediate

Abstract
Summarize what your training will cover, attendees will read this to get an idea of what they should know before training, and what they will learn after. Use this to section to broadly describe how technical your class is, what tools will be used, and what materials to read in advance to get the most out of your training. This abstract is the primary way people will be drawn to your session.

You need to send a message, avoiding traditional channels like email and SMS, to someone who's on a different network, somewhere else in the world. The tools at your disposal are Python, DNS, and an unauthenticated MQTT broker. This message must be end-to-end encrypted, and the recipient must be able to confirm that it was undeniably you who sent it. Now add another constraint: you can't communicate directly with this other party to perform a public key exchange before signing, encrypting, and transmitting the message. This can be a difficult problem to solve, and many specialized secure messaging apps have sprung up to address the challenge of end-to-end secured messaging. We will build our own. While our application won't be as sophisticated as Signal, you'll leave the workshop with an understanding of how DNS can be used to enable end-to-end authenticated and encrypted communication across nearly any public system that can be made to support the publisher/subscriber communication pattern.

Trainer Bio:
Ash is just some dude. In the past he's been a network engineer, created a variety of security tools, and is currently working in R&D and protocol development in spaces adjacent to email security. He has spoken at DEFCON, Black Hat, and Bsides San Diego. He has recently developed a weird fascination with hacking vintage electromechanical tech.