--On Saturday, October 31, 2015 5:06 AM +0000 Viktor Dukhovni
<ietf-dane@xxxxxxxxxxxx> wrote:
> On Fri, Oct 30, 2015 at 12:00:30PM +0100, Aaron Zauner wrote:
>
>> Starting up this thread again; our paper has been published
>> today open-access and our data-sets are currently in the
>> process of being published on scans.io.
>...
> What's missing here is that having trusted SSL certificates
> offers zero protection for MTA-to-MTA SMTP. Any time/money
> spend on such certificates is essentially wasted. Barring
> DANE or similar out-of-band policy, certificates *cannot*
> protect MTA-to-MTA SMTP from MITM attacks.
Viktor,
I appreciate your enthusiasm, but I'd like to suggest, again,
that, as people move from measurement and statistical analysis
(as in the parts of the paper by Aaron and his colleagues I
read) and into claims of protection and vulnerability we all be
very careful about extreme claims.
First, unless I'm missing a key part of your reasoning, if one
really had a "trusted SSL certificate" and used it properly,
"zero protection" seems like a dubious claim. I'd consider a
"trusted SSL certificate" to suggest an X.509 certificate with a
CA issuer whom one could verify and whose practices really
include verification of the applicant and the applicant's
ability to properly manage private keys. You may reasonably
claim that those criteria are almost never satisfied today and
that almost all TLS connections between SMTP sender and SMTP
receiver are made in the same casual way that almost all HTTPS
ones are. You may reasonably also claim that TLS with
self-signed certs (at least with no external knowledge or
prearrangement) fall somewhere on the scale between "useless"
and "only a fool would trust one, but there are a lot of fools
out there". I'd probably agree with both, but those are
problems with what users (who rarely have a clue about any of
this) and SMTP senders are willing to accept, not with the
certificate model itself.
Very similar comments apply to DANE-based certificates. Domains
are hijacked every day. Even where DNSSEC is deployed, many
users and even SMTP senders depend on DNS forwarding systems
that can be (and sometimes are) attacked and compromised and do
not have end to end DNSSEC verification. Whether the typical
registrar or registrar-agent is more or less scrupulous about
selling domain names and documenting and verifying purchasers
than the typical CA is about selling certificates (many of them,
today, based entirely on the ability to receive email at an
associated domain) is an open question but we all come out the
losers.
>...
> STARTTLS is designed to thwart exactly one attack: *passive*
> wiretap. It works as designed for just that attack. It is not
> surprising that active attacks can and do defeat STARTTLS,
Right. But that takes us back to active attacks to compromise
mail servers, queues, and/or mail stores, attacks that can be
(and historically almost certainly were) easier and more common
than activate attacks against transit links. If one is a state
actor trying to obtain message content, making such attacks by
administrative action is easier yet and requires no technical
skill at all. Also, if I were an attacker and could
successfully attack the SMTP receiver host, I might be able to
compromise the private (decryption) key, after which the link
encryption provides no useful protection either.
> Hence, DANE for SMTP and related efforts. No mass-scale use of
> end-to-end encryption is looming to save the day, so transport
> security is finally getting the attention it deserves. My DANE
> survey is at 9000 domains and counting, with adoption picking
> up the pace a bit lately. Some domain hosting providers have
> implemented tens of thousands of additional DANE domains that
> do not show up in my surveys. It is still very early in the
> process, but I am cautiously optimistic.
I am not, for the record, opposed to hop-by-hop transit
encryption and agree that good end to end approaches do not seem
to be on the horizon. But I think it is very important to be
careful about the claims that are made for what is protected and
how good that protection is. It seems to me that some of your
enthusiasm for DANR is not keeping to a high standard for being
careful about claims of protection.
best,
john