Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols

[Viktor Dukhovni <[e-mail]>]

On Fri, Feb 14, 2014 at 04:48:32PM -0800, Paul Hoffman wrote:

> Viktor's view gives us good MITM protection if the DNS channel
> is not broken and the client knows the DNSSEC status of its query.
> It also causes messages to be lost if there is an operational
> problem or even an unexpected mis-match on the crypto desires of
> the client and server. It also assumes that the person running the
> DNS server for a name is in active contact with the person operating
> the SMTP server.

Some comments on the above.

    - When authetication fails, the DANE SMTP draft specifies
      "delay" (aka defer, queue, ...) not bounce.  Provided the
      receving system operator fixes the server configuration in
      a reasonably timely manner, no mail is lost.

    - Crypto parameter mismatch for SMTP TLS is quite rare.  The
      only common problems are:

	* Microsoft Exchange 2003 only looks at the first 64 cipher
	  suites in the TLS client's SSL HELLO.  It has a broken
	  3DES implementation that mishandles CBC padding.  SMTP
	  clients that support TLS 1.2 typically have more 64 cipher
	  suites stronger than RC4-SHA and TLS connections to
	  Microsoft Exchange 2003 often fail after negotiating
	  3DES-CBC.  While such server are still found here and
	  there, operators of these would be foolish and unlikely
	  to publish TLSA records.

	* Some Debian "squeeze" systems have an Exim SMTP client
	  that was inadvisably patched by Debian to require 2048
	  bit or longer EDH primes.  These fail to handshake with
	  many servers that employ 1024 bit EDH primes.  These SMTP
	  clients do not implement DANE.  The patch has been reverted
	  in newer Debian releases.  When Exim supports DANE, we
	  can reasonably hope that Debian won't repeat their mistake.

    - As for "active contact", yes active contact is required after
      all to publish the TLSA record in the first place.  However,
      at tiny sites (say dukhovni.org) whose SMTP server certificate
      is long expired, but still pinned and thus valid enough for
      my MUA, "active contact" is a non-issue.  Simiarly, with
      DANE-EE(3) there is no need for "active contact" (though I
      admittedly am in "active contact" with myself).

      No "active contact is required" with DANE-TA(2).  The DNS
      folks and the folks operating the domain's CA publish new
      TLSA RRs for the latest CA keys from time time.  They issue
      new certs to the peons operating the SMTP server, these just
      work, because the TLSA RRs are CNAMEs pointing at the centrally
      managed TLSA RRset.

      Thus there are two reasonable models, that typically match
      smaller and larger organizations respectively, and don't
      impose undue operational burdens.  These are described in
      the SMTP and ops drafts.

-- 
	Viktor.