Re: [dns-privacy] Ben Campbell's Yes on draft-ietf-dprive-dns-over-tls-07: (with COMMENT)

"Ben Campbell" <ben@nostrum.com> Tue, 15 March 2016 14:42 UTC

Return-Path: <ben@nostrum.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 0C1A912D60F for <dns-privacy@ietfa.amsl.com>; Tue, 15 Mar 2016 07:42:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] 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 Plxls34oR0Hf for <dns-privacy@ietfa.amsl.com>; Tue, 15 Mar 2016 07:42:20 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 4998612DB8A for <dns-privacy@ietf.org>; Tue, 15 Mar 2016 07:42:12 -0700 (PDT)
Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2FEgAvO033062 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 15 Mar 2016 09:42:11 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10]
From: Ben Campbell <ben@nostrum.com>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Date: Tue, 15 Mar 2016 09:42:09 -0500
Message-ID: <4037E8E3-6B9A-4436-833F-5E392AB70844@nostrum.com>
In-Reply-To: <20160315141448.GA24783@nic.fr>
References: <20160315035859.11533.34536.idtracker@ietfa.amsl.com> <20160315141448.GA24783@nic.fr>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.4r5232)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dns-privacy/XJDO0WuZ4JVIC3u9NFRQvCeLtcA>
Cc: tjw.ietf@gmail.com, allison.mankin@gmail.com, draft-ietf-dprive-dns-over-tls@ietf.org, The IESG <iesg@ietf.org>, dprive-chairs@ietf.org, dns-privacy@ietf.org
Subject: Re: [dns-privacy] Ben Campbell's Yes on draft-ietf-dprive-dns-over-tls-07: (with COMMENT)
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, 15 Mar 2016 14:42:22 -0000

On 15 Mar 2016, at 9:14, Stephane Bortzmeyer wrote:

> On Mon, Mar 14, 2016 at 08:58:59PM -0700,
>  Ben Campbell <ben@nostrum.com> wrote
>  a message of 54 lines which said:
>
>> I'm balloting yes, but I do have a few comments/questions:
>>
>> - 3.1, third paragraph:
>> This seems to put normative requirements on clients and servers that 
>> do
>> not implement this draft. If that is really needed, then perhaps this
>> needs to update the appropriate base spec(s)?
>
> Old (not implementing this draft) DNS clients and servers will not use
> port 853 at all so this paragraph means nothing to them. (That's one
> of the reasons to use a dedicated port, instead of the original method
> of "upgrade to TLS" on port 53.)

Does this mean old servers cannot be configured to use 853 as an 
alternative port? (Then why have the normative language in the first 
place.)

>
>> - 4 and subsections:
>> There seems to be a notable absence of a profile that requires server
>> authentication but does not require pinning.
>
> The way I see it, the profiles in
> draft-ietf-dprive-dtls-and-tls-profiles-00, another DPRIVE work item,
> are not defined by the techniques they use but by the security
> properties they have. That's why the profile in
> draft-ietf-dprive-dtls-and-tls-profiles-00, section 6, for instance,
> says "domain name - authentified by X.509 or DANE - or pin".

Normally it would seem to me that the choice between authenticating and 
not authenticating changes the security properties in at least some 
situations. I can imagine configuring a host to use Google's DNS service 
because I did not want my ISP to see my DNS traffic, but not going to 
the trouble of pinning the certificate.

OTOH, It just occurred to me that I don't recall the draft talking about 
what name validation. (Maybe I missed or forgot it; I don't have the 
text in front of at the moment.) Depending on the choices there, (and 
assuming there's not much choice for DNS servers), I can see how 
non-pinned authentication might not add much.

Ben.