On 2013-03-27 at 12:33 +0000, Tony Finch wrote:
> Our response (as MTA authors) to a site with incomplete TLSA deployment
> should be, finish deploying it if you want proper security. That is where
> the effort should be applied.
>
> I should perhaps make the reasoning in the security considerations section
> clearer.
Your viewpoint seems reasonable and I think I'm persuaded. (And the
section update would be helpful).
> > I'm inclined to provide a mode which says "if some of the entries are
> > DNSSEC validated, but not all, then this is equivalent to no network
> > connectivity to the unsigned entries and they should be skipped, just as
> > if there were no route to the host".
>
> This is likely to have unhappy consequences if a site's third party backup
> MX gains TLSA records but its primary does not.
If that would lead to unhappy consequences, why are they advertising
that host as being acceptable to handle deliveries for them?
But you're winning me around. That, and the fact that it's simpler to
not reorder, so it's less work for me, as long as we think we're doing
the right thing for our userbase.
> Why do you think "dane" needs to be an option? Can't it be supported by
> default? I'm trying to write the specs so that it should just work from
> the point of view of the user/admin of client software.
Because changing what software does from one release to the next such
that it makes changes to how systems interoperate in the real world
leads to folks refusing to deploy it, because deploying the new version
causes breakages. Too many people don't read README.UPDATING as it is.
For a new feature like this, even without any MX reordering, we have to
make it explicit-enable at first, even if in a later version we switch
it to be on-by-default.
> I don't think making it a generic security= option fits the style of the
> existing TLS / AUTH options, which are fairly specific. So if you have to
> have a dane option it should look like dane=flag/flag/flag.
Oh, back towards my original design. :)
[ cert-only ]
> That is probably OK for an early prototype, but full TLSA support will be
> necessary.
Absolutely. I could just make libval a dependency, but I'm trying to
avoid having all of the DNSSEC validation happen inside Exim itself.
> > 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.
>
> Agreed, to some extent. This isn't too bad if the context is limited to
> just SMTP+DANE since the DNS restricts which CAs are trusted to
> authenticate a particular server. You are perhaps right to worry about the
> second-order effects, though they are dwarfed by the effects of which CAs
> browsers choose to trust.
Browsers are horribly insecure by default, they're waking up to it, and
each individual user of a computer (absent enterprise controls to the
contrary) can override decisions, so the impact can be limited. When I
visit
https://www.paypal.com/ in my browser, I can click on the browser
area that gives information about the certificate and glance at which CA
is issuing it.
Most people don't, but those who know enough can do so.
By contrast, once an email leaves the MUA, it's out of the user's
control, and they mostly just care about the mail getting through.
Postmasters who stop business proposals going through just because the
remote site has decided to require everyone to trust Incompetent Big CA
Foo (TooBigToFail), will find themselves seeking new employment.
Usage=0 or usage=1 in TLSA making their way into a store-and-forward
system leads to backpressure blackmail and a losing game for everyone
except those trying to extract rent from the security ecosystem.
> I think this is a bad idea. It sounds like it would introduce tricky error
> cases that could lead to spoofing, especially for usage=0. If the server
> wants usage=2 then they should say so.
I am willing to have a mode that does what you suggest here, but of all
the areas up for discussion, this is where I am most firm: I will not
knowingly create a system that creates such obvious backpressure
blackmail opportunities to have CAs make themselves ever more Too Big To
Fail, with postmasters faced with Hobson's Choice.
As long as TLS only allows one CA to be the anchor for a trust chain (or
forces clients to divulge an entire list of who they trust), the PKIX
interaction with TLS creates monopolistic tendencies which only barely
_almost_ managed to be usable for web-browsers. Still failed.
Actively aiding blackmail by designing support for it into a product we
maintain is a betrayal of the trust placed in us by our users.
So: by default we either reject and ignore usage=0/usage=1, or we treat
them as equivalent to usage=2/usage=3 (if the full certificate is
present). The latter approach has better security properties, since we
can at least verify that the certificate is the one the end host intends
to be available.
What do we _lose_ by mapping usage=0/1 to usage=2/3 ? We stop jumping
through hoops that have no bearing upon whether or not the remote site's
certificate (and thus public key) are the correct ones for the
connection.
What does a PKIX check here _add_, to the benefit of the sending site?
A trust anchor for being willing to check CRLs or OCSP ourselves (as
opposed to OCSP stapling)? We don't check those now. OCSP stapling
still works with usage=2 and is the only mode that doesn't add
significant single points of failure or other vulnerabilities to the
communication path models.
Perhaps I'm missing something important. I seriously am not seeing any
reason to check in PKIX given a certificate in TLSA/DNSSEC, other than
"the specification says we should".
That part of the specification should go the same way as SEND/SOML/SAML
from RFC 821.
Perhaps we can avoid ambiguity and create stronger pressure by only
implementing usage=2/usage=3, ignoring usage=0/1 entirely as Unusable?
My current design tries to salvage something from them, for those poor
sods forced by corporate policies to only ever use CA systems. We do
have meaningful data that can be used, provided the certificate is
present, and throwing away a valid security trust anchor for a Cause is
not to our users' benefit. Thus my intent to map 0/1->2/3.
-Phil
