On Thu, May 08, 2014 at 11:08:03PM +0200, Heiko Schlittermann wrote:
> But ? OTOH, if we always use DNSSEC (and fallback to DNS, remembering
> the answer is untrusted now), we have everything we need for the DANE
> checks, as soon as we see the certificate, haven't we?
Well, you also need to have pre-fetched the TLSA RRs, and configured
the right verification callbacks and associated state, because DANE
chain validation (including name checks) happens during the handshake.
Then once the handshake is complete, you have a boolean verified/
not verified state, on which to base policy, but the work that got
you there, needs to happen earlier.
> remote_smtps:
> driver = smtp
> hosts_require_tls = *
> tls_require_dane = yes # defaults to yes
> # but for using DNSSEC it's too late
> # already, because it's done in the
> # routers
Not sure what the "hosts_require_tls = *" means, if it means require
TLS for all destinations, that's rather impractical for the public
Internet.
The Postfix approach is to define TLS security levels:
- may Opportunistic unauthenticated TLS
- encrypt Mandatory unathenticated TLS
- dane Opportunistic DANE TLS
- dane-only Mandatory DANE TLS
- fingerprint Authentication by leaf fingerprint
- secure Authentication via PKIX CAs
Once you choose a level, the semantics of that level are built-in.
The levels come with optional parameters, so a policy table might
be:
tls_policy:
# No TLS with example.gov
example.gov none
# Leaf fingerprint checks with example.com
example.com fingerprint match={digest1} match={digest2}
# Mandatory DANE TLS for example.net
example.net dane-only
# Custom trusted CAs for example.org
example.org secure tafile=/etc/postfix/example.org.pem
# Custom cipher grade for example.edu
example.edu encrypt ciphers=high
...
If you just complete a handshake and give a user a chain and ask
then to validate everything in a Turing-complete extension language,
they'd have a rather difficult time implementing robust logic for
similar security levels (yes, level is not the best word).
--
Viktor.