On Sat, Dec 14, 2013 at 08:31:10AM -0500, John wrote:
> >DANE TLSA records allow sites to independently create leaf and CA
> >certificates after first registering their DNSSEC key-signing-keys
> >with their DNS registrar. So in effect you do have a CA, but it
> >is your DNS registrar and they effectively make you a sub-CA for
> >your own domain.
>
> Thanks I got some of the above. However I got DANE wrong.
>
> Does this do anything to solve "Man in the middle" who presents an
> apparently valid cert (usually generated on the fly)?
Any authenticated TLS ciphersuite does that. The challenge is
always key management. The public certificate authority PKI (
Verisign, Comodo, and the other couple of hundred CAs in the browser
bundles) is somewhat succesful in authenticating HTTPS, and largely
inapplicable to SMTP.
DANE provides a more scalable key management model. Each domain
signs its own server certificates either by directly publishing
their public key digests via DNSSEC, or by using its own issuing
CA to sign certificates for multiple services, and publishing just
the public key digest of the CA. [ See example below my signature. ]
> Because I thought the only way to detect this was to compare the
> finger print of the key presented with the know finger print.
With DANE, the "known finger print" is found in DNSSEC.
> Just a thought, maybe there is a more appropriate forum/mail list to
> discuss this on, as this is not strictly Postfix related?
It is fine to ask here, Postfix is the first real application to
support DANE TLSA.
--
Viktor.
Example: debian.org SMTP.
- The MX RRset is secure (my validating DNS server set the "ad" bit in
the response flags).
$ dig +dnssec +noall +comment +ans -t mx debian.org.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9595
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 5, ADDITIONAL: 19
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; ANSWER SECTION:
debian.org. 60 IN MX 0 mailly.debian.org.
debian.org. 60 IN MX 0 muffat.debian.org.
debian.org. 60 IN RRSIG MX 7 2 60 20140110192841
20131213192841 17309 debian.org. {base64-encoded signature}
- There are secure TLSA RRs for TCP port 25 each of the MX hosts:
$ dig +dnssec +noall +comment +ans -t tlsa _25._tcp.mailly.debian.org.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58643
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 11
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; ANSWER SECTION:
_25._tcp.mailly.debian.org. 3600 IN TLSA 3 1 1
709324DC1B427029F8E4D1D9F4159B85567099462CEFA6D5A099B442 2DE4DDA6
_25._tcp.mailly.debian.org. 3600 IN RRSIG TLSA 7 5 3600
20140110192841 20131213192841 17309 debian.org. {base64-encoded signature}
$ dig +dnssec +noall +comment +ans -t tlsa _25._tcp.muffat.debian.org.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59297
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 11
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; ANSWER SECTION:
_25._tcp.muffat.debian.org. 3600 IN TLSA 3 1 1
CDC19FDEADF1C5566A5DA79BA20EC5522022834FDCECA445889BA1CC 0A78BD35
_25._tcp.muffat.debian.org. 3600 IN RRSIG TLSA 7 5 3600 20140110192841
20131213192841 17309 debian.org. {base64-encoded signature}
- The public-keys of the server cerificates match the TLSA records:
$ get311() {
(sleep 1; printf "QUIT\r\n" ) |
2>/dev/null \
openssl s_client -showcerts -starttls smtp -connect "$1:25" |
openssl x509 -pubkey -noout |
openssl pkey -pubin -outform DER |
openssl dgst -sha256 |
awk '{print $NF}' |
tr '[a-z]' '[A-Z]'
}
$ dig +short -t mx debian.org |
sort -n | while read pref mx; do echo $mx $(get311 $mx); done
mailly.debian.org.
709324DC1B427029F8E4D1D9F4159B85567099462CEFA6D5A099B4422DE4DDA6
muffat.debian.org.
CDC19FDEADF1C5566A5DA79BA20EC5522022834FDCECA445889BA1CC0A78BD35
- Therefore debian.org's SMTP servers can be authenticated via their DNSSEC
TLSA records. And so man in the middle attacks on email to
debian.org from DANE TLSA enabled SMTP clients (e.g. Postfix 2.11
configured to use DNSSEC and DANE) require the attacker to
brute-force crypt-analyze TLS cryptography, or have access to either the
server's private keys, or the DNSSEC private keys of "debian.org",
"org" or the root zone.
