Re: [dns-privacy] More WGLC reviews for TLS Profiles draft?

Sara Dickinson <sara@sinodun.com> Tue, 13 December 2016 15:22 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 C01271293E3 for <dns-privacy@ietfa.amsl.com>; Tue, 13 Dec 2016 07:22:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 aiN-G3Br4YbD for <dns-privacy@ietfa.amsl.com>; Tue, 13 Dec 2016 07:22:31 -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 DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 282061296AD for <dns-privacy@ietf.org>; Tue, 13 Dec 2016 07:22:31 -0800 (PST)
Received: from [2001:b98:204:102:fffa::a] (port=52239) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <sara@sinodun.com>) id 1cGouS-0000U0-K8; Tue, 13 Dec 2016 15:22:29 +0000
From: Sara Dickinson <sara@sinodun.com>
Message-Id: <BB7C5127-32B2-4DC1-9F59-1975CC71642C@sinodun.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_429BF584-D621-4902-B435-2BAB79BD7EEF"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Date: Tue, 13 Dec 2016 15:22:23 +0000
In-Reply-To: <029001d251ba$2a7eddd0$7f7c9970$@huitema.net>
To: Christian Huitema <huitema@huitema.net>
References: <6cdc7899-f0f4-e735-a844-1a40bf1314fb@gmail.com> <EF0487AF-5D73-417F-A4C3-F3D42CCA3E05@sinodun.com> <029001d251ba$2a7eddd0$7f7c9970$@huitema.net>
X-Mailer: Apple Mail (2.3251)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: State = no_sa; Score =
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/u0mmHpBlTBt_HkuZjU436Ldcd7c>
Cc: dns-privacy@ietf.org
Subject: Re: [dns-privacy] More WGLC reviews for TLS Profiles draft?
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.17
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, 13 Dec 2016 15:22:34 -0000

> On 9 Dec 2016, at 01:18, Christian Huitema <huitema@huitema.net> wrote:
> 
> On Thursday, December 8, 2016 1:52 AM, Sara Dickinson wrote:
>> 
>> Just to follow up on Tim’s mail. Any reviews of https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/ would be much appreciated to try to wind up the WGLC asap. 

Hi Christian, 

> 
> I just reviewed this draft. I think it is ready, and I would be happy if it was published as is. 

Many thanks for the review. 

> 
> My only wish is for a bit more description of the interaction between policy and configuration. The selection of the strict or opportunistic profile is only one element in the configuration of the DNS client for privacy, the other element being obviously the choice of the DNS server. The strict mode, in particular, ought to depend on configuring a set of servers that the client will accept to trust -- but even the opportunistic mode depends on that to a degree. This is quite different from the current practice, in which DNS servers are configured by untrusted processes. It would be nice if we had a blow-by-blow example of how that's supposed to work. 


IIRC this was discussed a bit in Buenos Aires… and I believe the consensus was to have an example such as that in section 7.2.2  for Strict but to leave any other policy discussion out of this document hence the following sentence was added to Section 4:

"A description of the variety of usage policies is out of scope of this document, but may be the subject of future work.”

It seems there is some appetite for a follow up document on operational practices so perhaps that is where this policy discussion should be?

Sara.