On 14/12/2013 12:26 AM, Viktor Dukhovni wrote:
On Sat, Dec 14, 2013 at 12:04:15AM -0500, John Allen wrote:
The main difficulty with server-side DANE is that your zone
must be DNSSEC signed. Deployment of DNSSEC is still fairly thin.
With a bit of luck DANE might motivate folks to consider DNSSEC.
My interest in TLSA was sparked by my looking for info when setting
up my DNS with DNSSEC (still a work in progress). It seemed to
provide a better level of security than the current standard
practice.
The trick is to find tools that make operating a DNSSEC zone
relatively painless. You get security, but it easier to mess up
leaving the zone with stale signatures and thus essentially
invisible to all DNSSEC-aware clients. By all means deploy
DNSSEC, but carefully.
/*YEP*/, been there, and am doing that. e.g., today for no apparent
reason, ( I suspect a roll gone wrong) the KRF on one of my domains is
f....). I am still looking for /good/ tools.
If I have understood what I have read TLSA appears to be a
mechanism for publishing security certs is a secure manner.
My interest in TLSA lead me to DANE, I am not sure that I fully
understand DANE or TLSA, however my understanding is, that DANE is a
high(er) level TLS encryption standard.
You're naturally confused:
- DNSSEC: a man-in-the-middle hardened means of publishing DNS data.
- DANE: an IETF working group to develop standards for using DNSSEC
to publish authentication information (public keys and the like)
that binds DNS names to corresponding credentials.
http://datatracker.ietf.org/wg/dane/charter/
- TLSA: one of the DNS record types developed by the DANE working group
that publishes TLS server keys in DNS. TLSA records are defined in
RFC 6698.
http://tools.ietf.org/html/rfc6698
http://datatracker.ietf.org/doc/rfc6698/
So, neither DANE nor TLSA encrypt your data, TLS does that. DANE
TLSA DNS records can be used to authenticate your server (or for
you to authenticate other servers). Since the existing public CA
PKI is largely incompatible with MX record indirection (thus not
scalably usable for SMTP), I'm attempting to drive DANE adopting
for SMTP which will scale, provided DNSSEC gets off the ground.
http://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/
Postfix 2.11 will support DANE TLSA. Work is due to begin on similar
support in Exim based on library code for DANE TLS over OpenSSL that
grew out of the DANE support in Postfix. I'm hoping to participate
in making DANE TLSA support generally available in OpenSSL.
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)? Because I thought
the only way to detect this was to compare the finger print of the key
presented with the know finger print.
Just a thought, maybe there is a more appropriate forum/mail list to
discuss this on, as this is not strictly Postfix related?
JohnA
