Re: [dane] srv-09 comments
Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 17 February 2015 23:12 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 E17621A8884 for <dane@ietfa.amsl.com>; Tue, 17 Feb 2015 15:12:15 -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 JGxrl4e4yUc8 for <dane@ietfa.amsl.com>; Tue, 17 Feb 2015 15:12:13 -0800 (PST)
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 A7CEF1A1AB5 for <dane@ietf.org>; Tue, 17 Feb 2015 15:12:13 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 608FF282F4B; Tue, 17 Feb 2015 23:12:12 +0000 (UTC)
Date: Tue, 17 Feb 2015 23:12:12 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20150217231212.GT1260@mournblade.imrryr.org>
References: <20150216170123.GR1260@mournblade.imrryr.org> <54E22A70.8050705@cisco.com> <20150216180813.GT1260@mournblade.imrryr.org> <54E265A3.8040201@cisco.com> <1936971F-ED29-45AD-8683-E449DC9330F8@ogud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1936971F-ED29-45AD-8683-E449DC9330F8@ogud.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/tL-2zziYIT3UwCS3CFXkN3taPU4>
Subject: Re: [dane] srv-09 comments
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, 17 Feb 2015 23:12:16 -0000
On Tue, Feb 17, 2015 at 05:01:33PM -0500, Olafur Gudmundsson wrote: > I section 3.1 you say in paragraph 2: > > For this specification to apply, the entire DNS RRset that is returned MUST be ?secure? ? > > Well the word entire is redundant if you are talking about single DNS RRset, > BUT I think there are missing words i.e. the sentence should be: > > For this specification to apply, the entire chain of DNS RRset(s) that is returned MUST be ?secure? ? > > If the second interpretation is right some minor word-smithing in paragraph 3 is also needed. Yes, if indeed there is a "chain" (of CNAME/DNAME RRs) leading from the query domain to the owner domain of the answer records then the entire chain must be "secure". IIRC this much is already said elsewhere in the draft. Note that with security-aware non-validating stub-resolvers that trust the AD-bit from a validating iterative resolver (presumably one to which they have a secure communications path) the "chain" issue is largely handled by that upstream resolver. The upstream resolver will return AD=0 if any link in the chain is insecure. With for non-validating security-aware stub resolvers the application need only worry about "chains" if multiple resolver queries are required to get from the query domain to the final answer (i.e. the iterative resolver returns one or more CNAME, but not the final answer, and the application has to retstart with the final CNAME). Thus, for example, Postfix has code to chase CNAMEs by asking the resolver multiple times, and in *that* case it makes sure that the final AD bit is the "AND" of the AD bits of all the replies received. That code is rarely exercised, since in practice most iterative resolvers do the CNAME chasing internally before returning multiple CNAME RRs and the final answer in a single response. This creates an interesting edge-case for testing whether individual MX hosts (or SRV target hosts) live in a signed zone (that's the purpose of the A/AAAA queries in the SRV and SMTP drafts that gate the applicability of TLSA lookups): ; example.com is a signed zone ; example.com. IN MX 0 mail.example.com. mail.example.com. IN CNAME mail.example.net. _25._tcp.mail.example.com. IN TLSA 3 1 1 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 ; example.net is an "insecure" zone: ; mail.example.net. IN A 192.0.2.1 When a query for the "A" records of "mail.example.com." is sent to a validating iterative resolver, the response has a CNAME RR, an "A" RR and AD=0. However the query domain is actually "secure", the reason for "AD=0" is that the CNAME points into an "insecure" zone. To accomodate this edge-case, when the A/AAAA record returns an insecure CNAME, Postfix sends a second query: mail.example.com. IN CNAME ? and if that yields "AD=1", TLSA records are still requested: _25._tcp.mail.example.com. IN TLSA ? and used if returned (with AD=1). Now this case is atypical, because with MX and SRV records the target host is supposed to never be a CNAME (though it is in a small fraction of cases). So this issue legitimately arises only for email domains that have no MX RRs and use just A records to publish the available SMTP server(s). Nevertheless many MTAs tolerate MX hostnames that are aliases. Therefore the SMTP draft in section 2.2.2 (which covers the A/AAAA record lookup rationale and processing logic) says: [ ... Cases for possible replies to A/AAAA queries ... ] Insecure CNAME: The input domain is a CNAME alias, but the ultimate network address RRset is "insecure" (see Section 2.1.1). If the initial CNAME response is also "insecure", DANE TLS does not apply. Otherwise, this case is treated just like the non-CNAME case above, where a search is performed for a TLSA record with the original input domain as the candidate TLSA base domain. This type of detail is how the SMTP draft go to be 33 pages, while the SRV draft is noticeably shorter. :-) -- Viktor.
- Re: [dane] srv-09 comments Viktor Dukhovni
- [dane] srv-09 comments Viktor Dukhovni
- Re: [dane] srv-09 comments ⌘ Matt Miller
- Re: [dane] srv-09 comments ⌘ Matt Miller
- Re: [dane] srv-09 comments Olafur Gudmundsson
- Re: [dane] srv-09 comments ⌘ Matt Miller
- Re: [dane] srv-09 comments Viktor Dukhovni
- Re: [dane] srv-09 comments Paul Wouters
- Re: [dane] srv-09 comments Mark Andrews
- Re: [dane] srv-09 comments Viktor Dukhovni
- Re: [dane] srv-09 comments Mark Andrews