Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard

[John C Klensin <[e-mail]>]

--On Sunday, March 01, 2015 20:27 +0000 Viktor Dukhovni
<[e-mail]> wrote:

>...
>> > Whether your MTA uses STARTTLS or not is another matter
>> > but we can prevent downgrade attacks from succeeding.
> 
> If the MTA implements opportunistic DANE TLS, and usable TLSA
> records *are* published, then it MUST use STARTTLS and
> authenticate the peer via said TLSA records.
> 
> http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-14#s
> ection-2.2

Victor,

Please don't get too excited about statements like that, whether
they are written into I-Ds or not.  There are two separate
clusters of problems with it:

(1) Email, including SMTP, is based on a very old set of
protocols.  For reasons that are historical but still relevant
today, there is extensive deployment of the protocols in
embedded environments, many of them old enough that there has
been no option to upgrade them even to ESMTP and MIME, which are
now themselves over 20 years old.  Precisely because it works
well and is all but ubiquitous, email provides a communications
mechanism that has been plagued in recent years by spam,
phishing, and email-spread malware.  Those problems have brought
about operational changes and the "operational necessity" escape
clause in RFC 5321.  For other reasons, the mail system, almost
unique among IETF application protocols, is designed around a
hop by hop model, not an end to end one.  While that design was
originally important because of intermittently-connected
destinations and gateways to systems running other mail
protocols, it is now commercially vital for third-party
provisioning of enterprise mail systems (whether motivated by
antispam or other operational concerns).   As in the earlier
days, hop by hop models are difficult from a security standpoint
because the initiating client cannot be guaranteed to have the
ability to negotiate or handshake with the final destination
server.  It may be able to negotiate with an intermediate that
acts on the destination's behalf instead, but such negotiations
involve all of the difficulties with a trusted third party whose
identity and trustworthiness are hard to verify.

(2) The very essence of all, or almost all, mail-based phishing
attacks involves having someone accept a domain name, email
address, or URI as legitimate when it is actually not the
user-intended one.  Neither DNSSEC nor DANE prevent or detect
those attacks.  They may actually be harmful if they give the
user a false sense of security.  The main protections against
such attacks lie in user awareness, tools that identify or
highlight suspicious domain names or domains or addresses that
are known to be malicious, and a high degree of integrity by
registrars.  The latter has, at least IMO, proven to be a
failure.  In particular, when malicious parties can easily
register domains with misleading names, all DNSSEC does is to
verify that the DNS records were not altered in transit and DANE
is as happy to provide key material associated with a malicious
domain as a desirable one.

    john