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

Joe Touch <touch@isi.edu> Thu, 13 August 2015 18:08 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 EE95D1B2CD2 for <dns-privacy@ietfa.amsl.com>; Thu, 13 Aug 2015 11:08:34 -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 ShDJnG9zc9q7 for <dns-privacy@ietfa.amsl.com>; Thu, 13 Aug 2015 11:08:33 -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 C5E7A1B2CC8 for <dns-privacy@ietf.org>; Thu, 13 Aug 2015 11:08:33 -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 t7DI6S9P020032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 13 Aug 2015 11:06:29 -0700 (PDT)
To: Warren Kumari <warren@kumari.net>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
References: <CAHw9_iJ8QPyHqg2emJm4RfSnsiUcHFY7tGS3K9nL5HJYTyww_Q@mail.gmail.com> <55CA382A.9020707@isi.edu>
From: Joe Touch <touch@isi.edu>
X-Enigmail-Draft-Status: N1110
Message-ID: <55CCDCA3.6080203@isi.edu>
Date: Thu, 13 Aug 2015 11:06:27 -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: <55CA382A.9020707@isi.edu>
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/dO99_jjoBUrHS2hCNDKTNRlBLFo>
Cc: 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:08:35 -0000

FYI:

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".

Note: there have been several types of suffixes to indicate security:
-ssl, -tls, -sec, and more recently -s. Because there are many types of
security and to allow more characters for the remainder of the service
name, the -s suffix is currently preferred by the IANA Ports Review team.

Joe

On 8/11/2015 11:00 AM, Joe Touch wrote:
> 
> 
> On 8/7/2015 6:03 AM, Warren Kumari wrote:
>> Hi all,
>>
>> The chairs believe that there is sufficient interest in the working
>> group for early allocation of a port for dns over TLS, following RFC
>> 7120.
> 
> Hi, Warren,
> 
> It might be useful to summarize on this list the rationale for this
> allocation and the plan for its use.
> 
> In particular:
> 
> 	- why port 53 is not sufficient using STARTTLS
> 
> 	- why a system port, rather than a user port, is appropriate
> 
> 	- whether TLS-protected DNS would ever be expected on port 53
> 
> Speaking as an individual (though I also chair the IANA port expert
> review team, which reviews applications not through the standards
> process), my view is that:
> 
> 	a) it would have been preferable to use the existing
> 	assigned port for DNS (e.g., using STARTTLS), as I note
> 	in RFC7605
> 
> 	b) the existing ubiquity of DNS ALGs will make (a) difficult
> 	(this does not apply to new protocols but would here)
> 
> 	c) if the secure variant has a separate port, then it would
> 	be confusing to run the same service on multiple ports
> 
> 	d) if this service is assigned a new port, it should be
> 	a system port; although system ports do not often afford
> 	the protections once assumed, it seems reasonable to stay
> 	with the same type of port as the original service
> 
> As a result, I concur with the assignment of a port for "dns-s" (FWIW,
> that's what I would suggest, as it is the convention for most new secure
> variants) as a system port.
> 
> Joe
>