A slightly longer abstract:

Let's Encrypt has enabled rapid adoption of TLS across the long-tail of public-facing services. Unfortunately, there are still challenges in deploying TLS on home network devices, such as routers, TV tuners, and IoT hubs. These devices are commonly accessed by their non-routable, dynamically-assigned IP address, preventing traditional domain-validated certificates from being used. This talk introduces TLSMy.net, a new DNS-based service that allows home network devices to automatically request certificates that can be used with non-routable IP addresses.

Talk outline:

• Introduction
• Why TLS is important for local network devices
  • New web features (e.g., cross-origin resource sharing and requests) REQUIRE TLS to be used.
• Why TLS is hard to deploy locally
  • Home users don't typically own a domain -- no DV certs
  • Services aren't usually externally-facing, so certbot doesn't work
• How Plex solves the issue
  • IP.accountid.plex.direct
  • Requires cooperation with a CA
• What if we could use Plex's solution with Let's Encrypt?
• How Let's Encrypt issues certs
• Subdomain and wildcard rules
• ACME protocol
  • HTTP challenge
  • DNS challenge
• Let's Encrypt accounts
  • Public/private key
  • Public key is identity
  • Private key is used to authenticate
• Creating a DNS responder for wildcard addresses
• Maps a.b.c.d.pubkey.tlsmy.net to IP address a.b.c.d
• Updating DNS records for wildcard subdomain validation
  • Use challenge/response to verify permission to update *.pubkey.tlsmy.net
  • Proof of possession of private key
• Trust model
• Need to somewhat trust domain owner
  • If device manufacturer is domain owner, you may implicitly trust them anyway
• Can use certificate transparency logs to audit domain owner
• Getting adoption
• Overcoming Let's Encrypt rate limits
• Getting device vendors to support TLS
• Summary