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

Joe Touch <touch@isi.edu> Tue, 11 August 2015 18:01 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 49D691ACE52 for <dns-privacy@ietfa.amsl.com>; Tue, 11 Aug 2015 11:01:23 -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 DdyHA5MwfkLY for <dns-privacy@ietfa.amsl.com>; Tue, 11 Aug 2015 11:01:22 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37A711AC3E2 for <dns-privacy@ietf.org>; Tue, 11 Aug 2015 11:01:22 -0700 (PDT)
Received: from [128.9.184.100] ([128.9.184.100]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t7BI0HR6024033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 11 Aug 2015 11:00:33 -0700 (PDT)
To: Warren Kumari <warren@kumari.net>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
References: <CAHw9_iJ8QPyHqg2emJm4RfSnsiUcHFY7tGS3K9nL5HJYTyww_Q@mail.gmail.com>
From: Joe Touch <touch@isi.edu>
X-Enigmail-Draft-Status: N1110
Message-ID: <55CA382A.9020707@isi.edu>
Date: Tue, 11 Aug 2015 11:00:10 -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: <CAHw9_iJ8QPyHqg2emJm4RfSnsiUcHFY7tGS3K9nL5HJYTyww_Q@mail.gmail.com>
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/BOZvqcJAyK1QJannhwPKTtBgf98>
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: Tue, 11 Aug 2015 18:01:23 -0000


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