Re: [dane] Delivery of email if MX is not signed

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 24 August 2015 03:00 UTC

Return-Path: <ietf-dane@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 9BC0E1A0103 for <dane@ietfa.amsl.com>; Sun, 23 Aug 2015 20:00:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 KDXfXrreacrm for <dane@ietfa.amsl.com>; Sun, 23 Aug 2015 20:00:16 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30DA61A0102 for <dane@ietf.org>; Sun, 23 Aug 2015 20:00:16 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5B281284DA0; Mon, 24 Aug 2015 03:00:15 +0000 (UTC)
Date: Mon, 24 Aug 2015 03:00:15 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20150824030015.GD9021@mournblade.imrryr.org>
References: <D976ACCE-8F15-448C-A5E4-B8D1FD329A8B@frobbit.se> <alpine.LFD.2.20.1508231343110.26943@bofh.nohats.ca> <F2977CCF-CE1E-46F1-A08E-4A6D77EA3A74@frobbit.se> <alpine.LFD.2.20.1508231411280.26943@bofh.nohats.ca> <C6382564-E6D5-4461-902A-6E12ED78296C@frobbit.se> <20150823185057.GJ5112@x28.adm.denic.de> <0E722F2F-510C-4060-86C2-41190F724DBA@frobbit.se> <alpine.LFD.2.20.1508231528300.8057@bofh.nohats.ca> <F03DF898-2E5D-491B-8315-03F4E0F53323@frobbit.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <F03DF898-2E5D-491B-8315-03F4E0F53323@frobbit.se>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/tcwN4c24q4LiLDDyIwCPi6fCbBY>
Subject: Re: [dane] Delivery of email if MX is not signed
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: <https://mailarchive.ietf.org/arch/browse/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, 24 Aug 2015 03:00:17 -0000

On Mon, Aug 24, 2015 at 04:51:19AM +0200, Patrik F?ltstr?m wrote:

> I want the validation of the cert used for the TLS connection to use the
> same rules for trust regardless of whether DANE is used (i.e. signed and
> properly validated TLSA record for the peer) or if X.509 cert/PKI from
> some CA is in use.

What rules would that be?  Without DANE or local configuration,
SMTP does no authentication of the peer, for reasons explained in
Section 1.3 of the draft, that we don't need to repeat.

> What I read in the draft, and what I read in the paper Jan wrote after
> testing Postfix and what I read here in the responses I get is that DANE
> is trusted LESS than X.509 certs.

This is a misapprehesion on your part.

> 1. X.509
> 
> 1.1 Unsigned MX
> 1.2 cert validated from some CA that is trusted

No.  Non-DANE SMTP does unauthenticated TLS, and the cert is ignored,
whether its trust chain verifies or not.

> 2. DANE
> 
> 2.1 Unsigned MX
> 2.2 cert validated via signed TLSA with DNSSEC chain of trust to some TA

In both cases no authentication is performed.

> I think they should be equivalent.

They are equivalent, you get no protection from active attacks.

> If they are, also in the implementation in postfix, then just tell me and I'll shut up.

With "smtp_tls_security_level = dane", the two cases are treated
identically, neither authenticate the peer, and both deliver the
mail regardless of the content of the peer certificate if any.

-- 
	Viktor.