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

"Patrik Fältström " <paf@frobbit.se> Sun, 23 August 2015 18:30 UTC

Return-Path: <paf@frobbit.se>
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 B3DB71B2A0E for <dane@ietfa.amsl.com>; Sun, 23 Aug 2015 11:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.961
X-Spam-Level:
X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 IgzcfzZy__Bk for <dane@ietfa.amsl.com>; Sun, 23 Aug 2015 11:30:13 -0700 (PDT)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20DE61B2A0D for <dane@ietf.org>; Sun, 23 Aug 2015 11:30:13 -0700 (PDT)
Received: from [192.168.1.12] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id 22E1520025; Sun, 23 Aug 2015 20:30:11 +0200 (CEST)
From: Patrik Fältström <paf@frobbit.se>
To: Paul Wouters <paul@nohats.ca>
Date: Sun, 23 Aug 2015 20:30:10 +0200
Message-ID: <C6382564-E6D5-4461-902A-6E12ED78296C@frobbit.se>
In-Reply-To: <alpine.LFD.2.20.1508231411280.26943@bofh.nohats.ca>
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>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_3A5CC493-03BD-4213-BF84-895C0125E245_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
X-Mailer: MailMate (1.9.2r5107)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/bzhMbTSJa13LHPQPGmhYGAq0nkg>
Cc: dane@ietf.org
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:30:14 -0000

On 23 Aug 2015, at 20:18, Paul Wouters wrote:

>> 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 ....
>
> so anyone can spoof:
>
> example.net. IN MX 0 mail.example.com.

Yes, just like today.

> pretending "mail.example.com." does not give you more security. What
> would you do if you saw:
>
> example.net. IN MX 0 evil.nohats.ca
>
> with proper TLSA records for evil.nohats.ca?

This is what we have today.

I would deliver over the TLS secured connection.

The only way to secure that is to DNSSEC sign mail.example.net.

>> I.e. if only looking at mail.example.com. and _426._tcp.mail.example.com. that is a 100% properly setup DANE "thing".
>
> But nothing in that statement securely tells you anything about example.net.

Correct.

>> 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.
>
> That would be a bug in postfix? The spec states:
>
> All
> "insecure" RRSets MUST be handled identically: in either case
> unvalidated data for the query domain is all that is and can be
> available, and authentication using the data is impossible.
>
> It does not state to not deliver email, it just states there is no
> authentication possible, so deliver without dane authentication.

Ok, I think what I have issues with is that I think "dane authentication" is not black or white.

We have at least:

1. Signed and validated MX, signed and validated TLSA

2. Unsigned MX, signed and validated TLSA

3. Unsigned MX, no TLSA, unsigned A/AAAA

Then we have all of the failed situations, which include:

4. Signed, but broken signatures, on MX, signed and validated TLSA

5. Signed, but broken signatures, on MX, signed but broken signatures on TLSA

6. Unsigned MX, signed but broken signatures on TLSA

Etc

So if you look at 1, 2 and 3, if I understand you correctly, [2] is not "DANE authenticated" even if the TLS connection has properly signed and validated TLSA record?

This is a bit confusing to me. I.e. the terminology is confusing. To me, [2] has proper DANE validated TLS available for the SMTP connection.

But I completely agree there is an MiM possible for the unsigned MX. Just like we have today. And why we want DNSSEC deployed.

   Patrik