On 2013-03-25 at 00:41 -0400, Phil Pennock wrote:
> So, for Exim, and using Jeremy's "security=dane" suggestion (in
> preference to "dane") as a starting-point, I'm seeing these three
> options for a Router:
Uh, four.
> security = dane/prefertlsa
> security = dane/prefersecure
> security = dane/prefermxfirst
> security = dane/preservemxorder
I'm going to add to this an optional "/strict" modifier.
Here was my thinking, which is incorrect:
----------------------------8< cut here >8------------------------------
If "dane" is set, this does not turn on need_dnssec, but if the MX results are
secure, and if _$port._tcp.$host exists with a TLSA record for any one of the
results from the MX lookup, then in the Transport:
* unless tls_verify_certificates is also set on the Transport, only
usage 2 or 3 of TLSA apply, usage 0 or 1 will be equivalent to
dane not being set
* need_dnssec is coerced on (Router & Transport)
* tls_sni defaults to $host (if not explicitly set)
* hosts_require_tls is coerced on (if not explicitly set)
* tls_verify_hosts is coerced on (if not explicitly set)
* the trust-anchor from the TLSA record is written to
spool_directory/tlsa/$something
* for non-PKIX usages (2,3) we just use the trust-anchor directly in
TLS setup
* for PKIX usages (0,1), we first use the tls_verify_certificates to
confirm a path to the TLSA trust-anchor, and only if that
succeeds, then use the TLSA trust-anchor for TLS setup, just as
for usages 2/3.
----------------------------8< cut here >8------------------------------
The problem here came to light thinking through the usage=(0,1) cases,
but are the same for TLSA-less hosts.
If we suddenly are requiring CA conformance for any host which does not
have an independent trust-anchor, then this creates bad social pressures
on postmasters, to trust CA Foo just because BigImportantRecipient uses
CA Foo for their certs, even though CA Foo may have some "unfortunate"
practices. Saying "they cut off delivery to themselves" isn't going to
cut it when important mails are failing to go through: that's the type
of situation where jobs get put on the line for principles. We should
not facilitate creating those situations.
If CA Foo can get, eg, Government X to use their trust anchor, it
becomes much harder to argue against trusting CA Foo generally. If this
sounds far-fetched, think DigiNotar, who were also the CA for the NL
government certificate system.
Thus my current thinking: DNSSEC and "security = dane" turns on
"tls_try_verify_hosts = *". In the presence of a usage=(2,3) TLSA
record, this is elevated to "tls_verify_hosts = *" and we will
hard-reject certificate validation failures. In the presence of a
usage=(0,1) TLSA record, we attempt to validate the trust path to the
certificate in the record. If that fails, we proceed anyway, treating
it like a validation failure, but then for the TLS connection
certificate validation, we still treat a mis-match as a hard-reject
failure.
If the /strict modifier is used (with security = dane/strict equivalent
to security = dane/prefertlsa/strict) then we treat it as
tls_verify_hosts and a CA failure is a hard failure.
Folks might well end up with two Routers:
dnslookup_trustcas:
driver = dnslookup
domains = ! +local_domains : *.gov : *.mil
transport = remote_smtp
security = dane/strict
no_more
dnslookup:
driver = dnslookup
domains = ! +local_domains
transport = remote_smtp
security = dane
no_more
This seems to provide the balance of the most verifiable security, with
avoiding having sending sites being pressured into trusting CA Foo for
all users of their site, just because one has clout and insists on being
able to send to a site with CA Foo.
Sure, you can use tls_verify_certificates with a lookup of $host in a
"jackasses.db" file, to add more CAs, but that becomes a maintenance
nightmare and what would happen in practice is that CA Foo would become
trusted for everyone.
Thus goes my current thinking.
Feedback appreciated; am likely to code this weekend.
-Phil
