Re: [dns-privacy] Early port allocation request for dns-over-TLS

Joe Touch <touch@isi.edu> Thu, 13 August 2015 18:26 UTC

Return-Path: <touch@isi.edu>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C611B2DBC for <dns-privacy@ietfa.amsl.com>; Thu, 13 Aug 2015 11:26:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 LSTsehlT0E8H for <dns-privacy@ietfa.amsl.com>; Thu, 13 Aug 2015 11:26:44 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8630E1B2DEA for <dns-privacy@ietf.org>; Thu, 13 Aug 2015 11:26:37 -0700 (PDT)
Received: from [128.9.184.102] ([128.9.184.102]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t7DIP6nD023722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 13 Aug 2015 11:25:07 -0700 (PDT)
To: Paul Wouters <paul@nohats.ca>
References: <CAHw9_iJ8QPyHqg2emJm4RfSnsiUcHFY7tGS3K9nL5HJYTyww_Q@mail.gmail.com> <55CA382A.9020707@isi.edu> <55CCDCA3.6080203@isi.edu> <alpine.LFD.2.20.1508131412230.16179@bofh.nohats.ca>
From: Joe Touch <touch@isi.edu>
X-Enigmail-Draft-Status: N1110
Message-ID: <55CCE100.4030705@isi.edu>
Date: Thu, 13 Aug 2015 11:25:04 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <alpine.LFD.2.20.1508131412230.16179@bofh.nohats.ca>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/dns-privacy/eRXnq062lKzE7vPVaRAB3S_Sj3Q>
Cc: "dns-privacy@ietf.org" <dns-privacy@ietf.org>, Warren Kumari <warren@kumari.net>, touch@isi.edu
Subject: Re: [dns-privacy] Early port allocation request for dns-over-TLS
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 13 Aug 2015 18:26:45 -0000


On 8/13/2015 11:13 AM, Paul Wouters wrote:
> On Thu, 13 Aug 2015, Joe Touch wrote:
> 
>> Joe Abley reminded me off-list that the service name for DNS is
>> "domain", so my suggestion for the name for this new assignment would
>> then be "domain-s".
> 
> Why? Just let the "domain" reference die please, don't build on it.

There are a few reasons to build on "domain":

	- the current name is "domain", so if you want to
	associate this with the same service but add security,
	it's much more obvious to call it "domain-s"

	- the use of multiple service names for the same port
	is recommended against (RFC 6335), so it's no longer
	possible to assign both "domain-s" and "dns-s"

I.e., if you move to "dns-s" you're creating a distinct name for a
service that really isn't new -- it's just a secure alternate of an
existing service.

As to "dnstls", it might be convenient to speak out loud but it breaks
with current service name recommendations in several ways (new base
name, using the -tls suffix rather than -s), and I don't see a good
reason for this service to blaze a new trail compared to other service
assignments.

Besides, IMO, "domain-s" ought to suffice for any secure version,
including future ones that might use a different security mechanism than
TLS.

Joe