Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

Sara Dickinson <sara@sinodun.com> Tue, 14 November 2017 11:04 UTC

Return-Path: <sara@sinodun.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95F41200FC for <dns-privacy@ietfa.amsl.com>; Tue, 14 Nov 2017 03:04:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
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 VLo8y_mHPzjo for <dns-privacy@ietfa.amsl.com>; Tue, 14 Nov 2017 03:04:26 -0800 (PST)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 532461241F5 for <dns-privacy@ietf.org>; Tue, 14 Nov 2017 03:04:26 -0800 (PST)
Received: from [5.40.111.162] (port=63409 helo=[192.168.171.12]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <sara@sinodun.com>) id 1eEZ0y-0006OZ-P4 for dns-privacy@ietf.org; Tue, 14 Nov 2017 11:04:24 +0000
From: Sara Dickinson <sara@sinodun.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 14 Nov 2017 12:04:19 +0100
References: <878tfwey8w.fsf@fifthhorseman.net> <73F186C6-1F35-40B0-8C36-D4F011D11344@sinodun.com> <871slkd66k.fsf@fifthhorseman.net> <alpine.LRH.2.21.1710301539500.31082@bofh.nohats.ca> <7709D3C3-D879-421B-B81A-7908F521B9D5@sinodun.com> <E4F9F152-ACCA-4C75-A6A4-00E10B2025AB@vpnc.org>
To: dns-privacy@ietf.org
In-Reply-To: <E4F9F152-ACCA-4C75-A6A4-00E10B2025AB@vpnc.org>
Message-Id: <BFA37D35-D72A-451F-ADD3-7C464409B7F3@sinodun.com>
X-Mailer: Apple Mail (2.3273)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/tujncqlmCjhm68EDxoapt8MIiAY>
Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Nov 2017 11:04:29 -0000

Hi All, 

This draft is now ready to progress once a -12 version is available. I just want to circle back round to summarise the fact that the only proposed difference that will be in the -12 version compared to -11 is the following (in section 7.2. Direct configuration of ADN only): 

Current text:

“It can then use Opportunistic DNS connections to an untrusted recursive
   DNS resolver to establish the IP address of the intended privacy-
   enabling DNS resolver by doing a lookup of A/AAAA records.  Such
   records SHOULD be DNSSEC validated when using a Strict Usage profile
   and MUST be validated when using Opportunistic Privacy."

New text:
“It can then use Opportunistic DNS connections to an untrusted recursive
   DNS resolver to establish the IP address of the intended privacy-
   enabling DNS resolver by doing a lookup of A/AAAA records. A 
   DNSSEC validating client SHOULD apply the same validation policy
  to the A/AAAA meta-query lookups as it does to other queries.
  A client that does not validate DNSSEC SHOULD apply the same policy (if any)
  to the A/AAAA meta-query lookups as it does to other queries."

I hope I captured the consensus correctly? Please let me know as I intend to put out the -12 (final) version next Monday (20th). 

Sara. 

> On 31 Oct 2017, at 16:12, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> 
> On 31 Oct 2017, at 8:06, Sara Dickinson wrote:
> 
>> So maybe “A DNSSEC validating client SHOULD apply the same validation policy to the A/AAAA meta-query lookup as it does to other queries.”?
> 
> That could be misinterpreted to indicate that there has to be some positive validation policy. How about:
>   A DNSSEC validating client SHOULD apply the same validation policy
>   to the A/AAAA meta-query lookup as it does to other queries.
>   A client that does not validate DNSSEC SHOULD apply any policy it
>   has to the A/AAAA meta-query lookup.
> --Paul Hoffman