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

Viktor Dukhovni <viktor1dane@dukhovni.org> Mon, 17 February 2014 20:21 UTC

Return-Path: <viktor1dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745581A026E for <dane@ietfa.amsl.com>; Mon, 17 Feb 2014 12:21:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wb0_eHcLZc-U for <dane@ietfa.amsl.com>; Mon, 17 Feb 2014 12:21:53 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0279B1A025C for <dane@ietf.org>; Mon, 17 Feb 2014 12:21:52 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 190D22AABCE; Mon, 17 Feb 2014 20:21:50 +0000 (UTC)
Date: Mon, 17 Feb 2014 20:21:50 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140217202149.GK278@mournblade.imrryr.org>
References: <20140214200002.GK278@mournblade.imrryr.org> <m37g8x2trc.fsf@carbon.jhcloos.org> <B06F0F91-7200-4ACF-BBB5-7BDC942DBFB8@vpnc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <B06F0F91-7200-4ACF-BBB5-7BDC942DBFB8@vpnc.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Mpw5CpWTLitzLzxz6HS1s3bD020
Subject: Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Feb 2014 20:21:55 -0000

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.