Securing Security - DANE Introduction

• opportunistic encryption
• mandatory encryption

• STARTTLS works without a policy channel
• STARTTLS support of a peer is unknown before the connection attempt
• Attacker can strip the STARTTLS command from the unencrypted connection and downgrade the session to "Non-TLS"

220 mail.example.com ESMTP
EHLO client.example.com
250-mail.example.com
250-PIPELINING
250-SIZE 409600000
250-ETRN

250-STARTTLS

250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

In recent months, researchers have reported ISPs in the US and Thailand intercepting their customers' data to strip a security flag— called STARTTLS—from email traffic. (…) By stripping out this flag, these ISPs prevent the email servers from successfully encrypting their conversation, and by default the servers will proceed to send email unencrypted.

https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks

• Manual validation of certificates for certificate pinning
• Validation of certificates needs knowledge
• Validation of certificates requires work by a human
• Certificate changes at the peer must be monitored
• Manual certificate pinning does not scale

• Add a trusted policy channel to TLS
• Build a trust chain
• Signal encryption ability
• Communicate identity

• SMTP - binds service/server to one or more x509 certificates
• HTTP - binds service/server to one or more x509 certificates
• IPSEC - publishes the IPSec encryption configuration for a host
• OpenPGP - connects a public PGP/GPG key to an email address
• S/MIME - binds an email address to x509 certificates
• DoH/DoT - provides authentication for DNS encryption

DANE is not the only technology that aims to improve the security of the Internet PKI (PKIX):

• Certificate Transparency - provides an immutable log of issued certificates - can be used to detect misuse of the CA system (after the fact)
• CAA-Record - publishes a policy that binds a domain to one or more certification authorities (CA)

• Key Pinning
  • HPKP - HTTP Public Key Pinning - RFC 7469 (deprecated)
  • MTA-STS - SMTP MTA Strict Transport Security - RFC 8461
  • Key Pinning had issues and is not widely deployed
    • Qualsys: HKPK is dead
    • Google Chrome has removed HKPK in Version 78 (Current Version is 118)

Deprecate support for public key pinning (PKP) in Chrome, and then remove it entirely.

• DNS has been developed in 1983 as an lightweight, networked hierarchical database for Internet infrastructure information
• DNS has been used mostly for name and address lookups in the early years
• DNS is now becoming the preferred channel to publish security policy information for Internet services

• DANE (TLS policy via DNS - the topic of our workshop)
• CAA (Restricting certificate issuing)
• DKIM/DMARC/SPF (Email security)
• Authentication token for internet services (the TXT records at the domain root)
• HTTPS Records (Public key for TLS "encrypted client hello")
• MTA-STS (SMTP-TLS policy via HTTPS)
• SSHFP (SSH fingerprints)
• IPSec (IPSec configurations)

• The original DNS system has no build-in security
  • Attacking DNS data is not hard (cache poisoning, DNS spoofing)
  • DNS data might be communicated by untrusted parties (operators for secondary services, insecure DNS resolver caches)
• DNSSEC adds authentication and integrity proof to DNS
  • Recipients of DNS data can validate the origin and the content of the DNS data

• Policy data in DNS demands DNSSEC
• DANE requires DNSSEC to work
• Operating other DNS based policy methods without DNSSEC severely weakens the security of these policy methods

DNS based policy data without DNSSEC is like having a strong secured iron door inside a paper wall.