Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-chain-query

Paul Wouters <paul@nohats.ca> Tue, 17 November 2015 06:40 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA741B2AD2 for <dnsop@ietfa.amsl.com>; Mon, 16 Nov 2015 22:40:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.686
X-Spam-Level:
X-Spam-Status: No, score=-0.686 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.585] 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 K9-kBEpXB9ja for <dnsop@ietfa.amsl.com>; Mon, 16 Nov 2015 22:40:46 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 0F8BA1B2ACD for <dnsop@ietf.org>; Mon, 16 Nov 2015 22:40:46 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3p0Hhp6XWmz3Lv; Tue, 17 Nov 2015 07:40:42 +0100 (CET)
Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=XmYeibe/
X-OPENPGPKEY: Message passed unmodified
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 8Sr-AZuB4ttL; Tue, 17 Nov 2015 07:40:41 +0100 (CET)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 17 Nov 2015 07:40:40 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPS id 7173A8009F; Tue, 17 Nov 2015 01:40:39 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1447742439; bh=pvoMYeLrDUzllNy6DUdsaqjl9IQSVjJo39QZSh/yrxg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=XmYeibe/KBrxegU5Zdg4qbbZJ58oDhqpt2REwk7seig4sU5TawoyuHCSqB+kA5ZMv o6VEyhYRenhip0JGr7uOe4l6bm/wjorCiL5ipPVbq7xoxb7ejncZdw4rK51LuIPA24 DdwAZjsGCB9GtAk3Dsr2sYVkOHmOe0d6LPXnV+50=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id tAH6ecX4002961; Tue, 17 Nov 2015 01:40:39 -0500
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Tue, 17 Nov 2015 01:40:38 -0500 (EST)
From: Paul Wouters <paul@nohats.ca>
To: Shumon Huque <shuque@gmail.com>
In-Reply-To: <CAHPuVdUPCri1Pa0BrTG+TSffp-x4ucbkXDbNSe=egaL+JOnQCg@mail.gmail.com>
Message-ID: <alpine.LFD.2.20.1511170140230.2914@bofh.nohats.ca>
References: <5635CF1A.4030803@gmail.com> <CAHPuVdUPCri1Pa0BrTG+TSffp-x4ucbkXDbNSe=egaL+JOnQCg@mail.gmail.com>
User-Agent: Alpine 2.20 (LFD 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/P5XRlsrSxpywJ4rQiiZuc_OuQiA>
Cc: Tim Wicinski <tjw.ietf@gmail.com>, dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-chain-query
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Nov 2015 06:40:48 -0000

On Mon, 9 Nov 2015, Shumon Huque wrote:

> I've read this document and think it proposes a useful capability.

Thanks for your feedback Shumon! (I think you read -03 and not -04)

> Some other quick comments:
> 
> > This document specifies an EDNS0 extension that allows a validating
> > Resolver running as a Forwarder to open a TCP connection to another
> > Resolver and request a DNS chain answer using one DNS query/answer
> > pair.
> 
> The definition of "Forwarder" being used here conflicts with the
> definition in existing DNS protocol documents (e.g. RFC2308) and
> also in the new draft-ietf-dnsop-dns-terminology document.

I've changed the text to:

             This document defines an EDNS0 extension that can be used
             by a security-aware validating Resolver configured to use
             a Forwarder to send a single query, requesting a complete
             validation path along with the regular query answer.

(the text was already somewhat changed from before)

> > Closest Trust Point, a variable length FDQN of the requested start
> > point of the chain.
> 
> FDQN --> FQDN. But it is probably worth being more explicit. I assume
> you mean a fully qualified domain name in DNS wire format.

Done.

> To follow-up on in-person discussion that happened at the last dnsop
> meeting, this last sentence seems to imply an ordered sequence of RRsets
> in the authority section comprising the chain. Since consensus is
> against introducing ordering of RRsets in DNS message sections, this
> should probably be reworded.

Added:

 	The added RRsets MAY be added in matching hierarchical
 	order but a DNS client MUST NOT depend on the order of the
 	added RRsets for validation.

> > A DNS query that contains the CHAIN option MUST also have the DNSSEC
> > OK bit set.  If this bit is not set, the CHAIN option received MUST
> > be ignored.
> 
> What is the expected behavior if the requestor sets the CD bit?

Text changed to:

             A DNS query that contains the CHAIN option MUST also have
              the DNSSEC OK ("OK") bit set. If this bit is not set,
              or if the Checking Disabled ("CD") bit is set, the CHAIN
              option received MUST be ignored.

> > missing NS records.  Therefore, CHAIN responses MUST include the NS
> > RRset from the child zone, including the RRSIG records required for
> > validation.
> 
> What is meant by "the NS RRset from the child zone"? Should this be the
> NS RRset of the zone containing the queried name?

The NS RRset lives at the child (authoritative and signed) and at the
parent (unsigned glue). We want the signed set, not the unsigned set. I've
changed the text.

> I understand the stated rationale for including NS RRsets. On the other
> hand this makes it less likely that the TLS chain extension would use
> this message format (because of size considerations) rather than its
> current format of a sequence of RRsets (a discussion that is happening
> around that draft).

Okay, I've reworded it and loosened the MUST to a SHOULD unless space considerations
are important:

            CHAIN responses SHOULD include the NS RRset from the zone itself
            including the RRSIG records required for validation. It MUST
            NOT include the NS RRset from parent zone, as this RRset is
            not signed. If the size of the answer is an important factor,
            the NS RRset MAY be omited.

Paul