[Cryptography] MITM watch - Tor exit nodes patching binaries

Viktor Dukhovni cryptography at dukhovni.org
Wed Dec 3 14:25:04 EST 2014

On Wed, Dec 03, 2014 at 02:39:32PM +0000, ianG wrote:

> (*) I'd love to hear a better name than Bayesian impossibility syndrome,
> which I just made up.  It's pretty important, it explains why the current
> SSL/PKI/CA MITM protection can never work, relying on Bayesian statistics to
> explain why infrequent real attacks cannot be defended against when
> overshadowed by frequent false negatives.

Whether this is the crux of the matter or not, I think the remedy
is in large part to drive down the false negatives.  This is why
the DANE OPS draft updates RFC 6698 to explicitly ignore the
certificate expiration date with DANE-EE(3) TLSA records.  One of
the most frequent false negatives is "expiration", with administrators
not always deploying new certificates (a manual process in most
cases) in a timely manner.

Provided DNSSEC zone re-signing is automated, as it can and should
be, "IN TLSA 3 1 1" records, re-signed as-is, work indefinitely.
Key rotation is when the administrator decides, rather than when
a clock tick catches him unawares.

A parallel effort to drive down false negatives is to make sure
that buggy DNSSEC nameservers are upgraded.  At present, and
particularly in .nl, there are (early adopter) DNSSEC hosting
providers whose nameservers don't do Denial-of-Existence to spec.
I've notified the registrars in question and the .nl registry is
working with them to address the problem.

Patrick Koetter at sys4.de and I are developing a DANE TLSA test
site, that will help administrators test their SMTP server TLSA
deployment, so that they can catch errors before the rest of the
world does.  (And help them avoid errors in the first place).
We'll be announcing that soon.

I hope that by early 2015 false negatives with DANE TLSA for SMTP
can be made sufficiently rare to allow sending systems to enable
verification without having to engage in constant exception
management, that might lead one to always disable verification on
failure, even when there's a real attack (Bayesian impossibility
syndrome if you like).

If one of the large 800lb primates enables outbound verification,
(no need to deploy DNSSEC for their own domain to check others),
problems will become self-correcting, as loss of a large fraction
of inbound mail will quickly alert any site that screws up that
they have a problem to fix.  Everyone else benefits from the
pressure exerted by the large players.

If anyone on this list is in a position to influence SMTP (at least
outbound validation) DANE TLSA deployment at Gmail, Yahoo, AOL,
Microsoft, cable providers,  ... please get in touch.  Q1/Q2 of
2015, is I think a good target for such deployments, in that I
think the .nl problem should be under control by then.


More information about the cryptography mailing list