Status of opportunistic encryption

[Victor Duchovni]

On Mon, May 29, 2006 at 07:21:29AM +0200, Florian Weimer wrote:

> * Sandy Harris:
> 
> > Recent news stories seem to me to make it obvious that anyone with privacy
> > concerns (i.e. more-or-less everyone) should be encrypting as much of their
> > communication as possible. Implementing opportunistic encryption is the
> > best way I know of to do that for the Internet.
> >
> > I'm somewhat out of touch, though, so I do not know to what extent people
> > are using it now. That is my question here.
> 
> It seems to me opportunistic encryption has moved to the application
> layer, at least as far as Internet mail is concerned.  Many MTAs use
> TLS automatically with whatever certificates they can get.  Of course,
> this only guards against active attacks, but it seems to me that this
> is a reasonable threat model.

It only guards against *passive* eavesdropping. Active attacks can
forge DNS MX records, inject BGP routes, ... Actual MITM resistant
peer authentication with SMTP+TLS is extremely rare. I know it happens
sometimes because I have it running for a small number of destinations,
otherwise I would suspect that nobody is doing it.

    http://www.postfix.org/TLS_README.html#client_tls_harden

Once the new 2.3 TLS code is folded into the production Postfix 2.3
snapshots (at which point the new documentation will be published), see

    http://www.postfix.org/TLS_README.html#client_tls_levels
    http://www.postfix.org/TLS_README.html#client_tls_policy

Preview:

  It is regrettably the case, that TLS secure-channels (fully authenticated
  and immune to man-in-the-middle attacks) impose constraints on the sending
  and receiving sites that preclude ubiquitous deployment. One needs to
  manually configure this type of security for each destination domain,
  and in many cases implement non-default TLS policy table entries for
  additional domains hosted at a common secured destination. With Postfix
  2.3, we make secure-channel configurations substantially easier to
  configure, but they will never be the norm. For the generic domain with
  which you have made no specific security arrangements, this security
  level is not a good fit.

  Historical note: while the documentation of these issues and many of
  the related features are new with Postfix 2.3, the issue was well
  understood before Postfix 1.0, when Lutz Jaenicke was designing
  the first unofficial Postfix TLS patch. See, his original post
  http://thread.gmane.org/gmane.ietf.apps-tls/304/focus=304 and the first
  response http://thread.gmane.org/gmane.ietf.apps-tls/304/focus=305. The
  problem is not even unique to SMTP or even TLS, similar issues exist
  for secure connections via aliases for HTTPS and Kerberos. SMTP merely
  uses indirect naming (via MX records) more frequently.

I should also note that once one abandons the (still) unrealistic
assumption of a secure DNS, it is not just SMTP + TLS that runs into
trouble.

For example, many Kerberos client libraries do a forward lookup (to
alias- expand CNAMEs) and some perversely a reverse lookup (often the
owner of the IP address is the worst source of the machine's name), and
then give you a mutually authenticated channel to whatever principal
they construct from now rather questionable data. This carries over
to SASL GSSAPI, where GSSAPI abstraction makes working around this
(in practice nobody tries even with native Kerberos) even harder.

Consequently, also SSH with GSS KEX, is not MITM resistant when the
attacker can tamper with DNS responses.

Ultimately, to close similar security issues in many other protocols,
we need a secure DNS, but I am somewhat pessimistic about the likelihood
of this happening soon.

-- 

 /"\ ASCII RIBBON                  NOTICE: If received in error,
 \ / CAMPAIGN     Victor Duchovni  please destroy and notify
  X AGAINST       IT Security,     sender. Sender does not waive
 / \ HTML MAIL    Morgan Stanley   confidentiality or privilege,
                                   and use is prohibited.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com