Re: [dane] Barry Leiba's Discuss on draft-ietf-dane-smtp-with-dane-17: (with DISCUSS and COMMENT)
Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 26 May 2015 01:28 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 6BC3D1A1EF1; Mon, 25 May 2015 18:28:16 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001] 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 SEYOnyHHl8W2; Mon, 25 May 2015 18:28:14 -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 7A05C1A1BF8; Mon, 25 May 2015 18:28:14 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E3357283015; Tue, 26 May 2015 01:28:12 +0000 (UTC)
Date: Tue, 26 May 2015 01:28:12 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dane@ietf.org, draft-ietf-dane-smtp-with-dane@ietf.org
Message-ID: <20150526012812.GP17272@mournblade.imrryr.org>
References: <20150524204121.31745.72546.idtracker@ietfa.amsl.com> <20150525020430.GK17272@mournblade.imrryr.org> <841AFD92-8615-43BF-98B4-48770FA72235@ogud.com> <20150526000338.D70AC2F50D87@rock.dv.isc.org> <alpine.LFD.2.11.1505252020130.5996@bofh.nohats.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.LFD.2.11.1505252020130.5996@bofh.nohats.ca>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/0YocMXnyes63d7rkJ1vVtwhX4Ig>
Subject: Re: [dane] Barry Leiba's Discuss on draft-ietf-dane-smtp-with-dane-17: (with DISCUSS and COMMENT)
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: Tue, 26 May 2015 01:28:16 -0000
On Mon, May 25, 2015 at 08:31:23PM -0400, Paul Wouters wrote: > >If the A/AAAA is insecure the TLSA lookup will be insecure due to > >there being not DNSSEC trusted path the TLSA node. > > I don't understand this. Let's make it specific. If the zone containing smtp.example.com. IN A 192.0.2.1 is unsigned (whether because example.com is unsigned, or because "smtp.example.com" is itself a delegated 'insecure' zone), then it is exceedingly unlikely (a miracle) if somehow the associated TLSA RRset: _25._tcp.smtp.example.com. IN TLSA 3 1 1 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 is "secure". For that to happen, there would have to be an explicit DNSSEC trust-anchor for either "_tcp.smtp.example.com" or "_25._tcp.example.com" configured in the validating resolver. Since that's going to happen basically "never", the client just assumes the inevitable outcome, and avoids the lookup. The canonical problem case is "nist.gov". Their zone is signed and MX lookups yield a "secure" result: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52380 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 nist.gov. MX 0 nist-gov.mail.protection.outlook.com. If address record lookups that lead to "insecure" answers: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2284 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 nist-gov.mail.protection.outlook.com. A 207.46.163.247 nist-gov.mail.protection.outlook.com. A 207.46.163.170 nist-gov.mail.protection.outlook.com. A 207.46.163.138 are not used to infer that "TLSA" is also "insecure" and thus to suppress TLSA lookups, then TLSA lookups fail, and to avoid "downgrade" attacks no mail is delivered to "nist.gov". ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60707 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;_25._tcp.nist-gov.mail.protection.outlook.com. IN TLSA Such failures would make deployment of DANE TLS for SMTP unattractive to MTA administrators. The proposed language (implemented in Postfix and Exim) avoids this problem. We've discussed this before. > Wether the A/AAA is spoofed or someone > with sufficient power to redirect routing of that range to them > is the same thing. The A/AAAA lookups serve to discover whether the zone with the server name is signed. We don't actually care whether the address records are secure. We could query for any other record that "bare-bones" nameservers don't mishandle, but since the A records will be needed anyway, we use those. > I don't like that because I would like to be able to publish TLSA > records in my nohats.ca zone pointing to some mail service I use > that uses certificates but are not themselves dnssec signed. eg: > > nohats.ca. IN MX 5 mail.insecure-bigmail.com. > nohats.ca. IN TLSA <blob> This does you no good anyway, because queries for TLSA records with MX and SRV services are made for the "_<port>._tcp.<target host>" NOT "_<port>._tcp.<service domain>". Nor are you particulary likely to reliably publish accurate TLSA records for a server operated by a third party. Inevitably they'll make changes on their end, and your mail will stop. So this is not an option. > As for insecure TLSA records themselves, while I would prefer we > would use them in a better-than-nothing sense, I am more fearful of > implementations just not bothering or forgetting to check for DNSSEC > and blindly trusting these. So I think it is more clear to just say > ignore insecure TLSA records. I think we agree on that. -- Viktor.
- [dane] Barry Leiba's Discuss on draft-ietf-dane-s… Barry Leiba
- Re: [dane] Barry Leiba's Discuss on draft-ietf-da… Viktor Dukhovni
- Re: [dane] Barry Leiba's Discuss on draft-ietf-da… Olafur Gudmundsson
- Re: [dane] Barry Leiba's Discuss on draft-ietf-da… Mark Andrews
- Re: [dane] Barry Leiba's Discuss on draft-ietf-da… Paul Wouters
- Re: [dane] Barry Leiba's Discuss on draft-ietf-da… Viktor Dukhovni
- Re: [dane] Barry Leiba's Discuss on draft-ietf-da… Mark Andrews
- Re: [dane] Barry Leiba's Discuss on draft-ietf-da… Paul Wouters
- Re: [dane] Barry Leiba's Discuss on draft-ietf-da… Mark Andrews
- Re: [dane] Barry Leiba's Discuss on draft-ietf-da… Barry Leiba
- Re: [dane] Barry Leiba's Discuss on draft-ietf-da… Stephen Farrell
- Re: [dane] Barry Leiba's Discuss on draft-ietf-da… Barry Leiba
- Re: [dane] Barry Leiba's Discuss on draft-ietf-da… Viktor Dukhovni
- Re: [dane] Barry Leiba's Discuss on draft-ietf-da… Stephen Farrell
- Re: [dane] Barry Leiba's Discuss on draft-ietf-da… Barry Leiba