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

lst_hoe02@kwsoft.de Sun, 23 August 2015 18:39 UTC

Return-Path: <lst_hoe02@kwsoft.de>
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 BE0BC1B2A1C for <dane@ietfa.amsl.com>; Sun, 23 Aug 2015 11:39:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.26
X-Spam-Level:
X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 P4Z41PYL8_N2 for <dane@ietfa.amsl.com>; Sun, 23 Aug 2015 11:39:26 -0700 (PDT)
Received: from mailer.kwsoft.de (mailer.kwsoft.de [213.164.67.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22EDD1B2A1A for <dane@ietf.org>; Sun, 23 Aug 2015 11:39:26 -0700 (PDT)
Received: from mailer (localhost [127.0.0.1]) by mailer.kwsoft.de (Postfix) with ESMTP id 8030D181156 for <dane@ietf.org>; Sun, 23 Aug 2015 20:39:24 +0200 (CEST)
Received: from ftp (ftp.kwsoft.de [213.164.67.83]) by mailer.kwsoft.de (Postfix) with ESMTPS id C8633180DDB for <dane@ietf.org>; Sun, 23 Aug 2015 20:39:23 +0200 (CEST)
Received: from p54986CB5.dip0.t-ipconnect.de (p54986CB5.dip0.t-ipconnect.de [84.152.108.181]) by webmail.kwsoft.de (Horde Framework) with HTTP; Sun, 23 Aug 2015 20:39:23 +0200
Date: Sun, 23 Aug 2015 20:39:23 +0200
From: lst_hoe02@kwsoft.de
To: dane@ietf.org
Message-ID: <20150823203923.Horde.tB2fdE287dvPnQ0vGJjMYhv@webmail.kwsoft.de>
In-Reply-To: <F2977CCF-CE1E-46F1-A08E-4A6D77EA3A74@frobbit.se>
References: <D976ACCE-8F15-448C-A5E4-B8D1FD329A8B@frobbit.se> <alpine.LFD.2.20.1508231343110.26943@bofh.nohats.ca> <F2977CCF-CE1E-46F1-A08E-4A6D77EA3A74@frobbit.se>
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-1"; boundary="----=_Part_875_530035262.1440355164426"
User-Agent: Horde Application Framework 5
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/mNPRoKYhhHUOFqWLUk0UbUL9DMQ>
Subject: Re: [dane] Delivery of email if MX is not signed
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Sun, 23 Aug 2015 18:39:27 -0000

Zitat von Patrik Fältström <paf@frobbit.se>:

> On 23 Aug 2015, at 19:47, Paul Wouters wrote:
>
>> On Sun, 23 Aug 2015, Patrik Fältström wrote:
>>
>>> Also, in my example the RRSet the MX is in is _unsigned_:
>>>
>>> example.com. IN MX 0 mail.example.net.
>>>
>>> 2. Delivery of the mail over TLS to mail.example.net.
>>
>> so example.com is unsigned? and mail.example.net is signed, and the TLSA
>> record in example.net is signed.
>
> Correct.
>
>> In that case, I believe TLS will be used but the TLSA cannot be
>> verified, so while delivery happens over TLS, there is no way to
>> verify the identity of the receiver because the MX record could have
>> been spoofed.
>
> Excuse me for being slow here. What do you mean by "the TLSA cannot  
> be verified"?
>
> To be more precise:
>
> Unsigned RRSET contain:
>
> example.net. IN MX 0 mail.example.com.
>
> Signed (and properly validated) RRSETs that contains these two  
> records and a few more:
>
> mail.example.com. IN A 192.168.1.1
> _426._tcp.mail.example.om. IN TLSA ....
>
> I.e. if only looking at mail.example.com. and  
> _426._tcp.mail.example.com. that is a 100% properly setup DANE  
> "thing".
>
>> I think you are arguing that it should deliver TLS only after validation
>> of the TLSA record for mail.example.net. That validation is a false
>> sense of security though.
>>
>> I don't think mail delivery will be halted. since the example.com domain
>> is unsigned, anonymous TLS will be used when available, and no
>> verification will take place.
>>
>> I'm not sure what you are proposing to change?
>
> I am not sure I am proposing a change. :-)
>
> What seems to have happened in the tests that Jan did was that IF  
> the MX was not signed, BUT the TLSA was signed and validated  
> correctly, THEN postfix did _NOT_ deliver the email. At all.
>
> I think that behaviour is wrong, and am unsure whether it is a bug  
> in postfix or whether it is a bug in the spec.

To my knowledge with Postfix this should lead to a "normal" TLS  
connection with no DANE at all for "dane" level:

"The Postfix SMTP client will not look for TLSA records associated  
with MX hosts whose "A" or "AAAA" records lie in an "insecure" DNS  
zone."

With dane-only the connection might fail.

Regards

Andreas