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

Stephane Bortzmeyer <bortzmeyer@nic.fr> Tue, 15 March 2016 14:24 UTC

Return-Path: <bortzmeyer@nic.fr>
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 4048E12D5B9 for <dns-privacy@ietfa.amsl.com>; Tue, 15 Mar 2016 07:24:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 CHCxR9vLdgiX for <dns-privacy@ietfa.amsl.com>; Tue, 15 Mar 2016 07:24:28 -0700 (PDT)
Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04B7D12DB5A for <dns-privacy@ietf.org>; Tue, 15 Mar 2016 07:24:12 -0700 (PDT)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 6B293280695 for <dns-privacy@ietf.org>; Tue, 15 Mar 2016 15:24:10 +0100 (CET)
Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 66EE7280655 for <dns-privacy@ietf.org>; Tue, 15 Mar 2016 15:24:10 +0100 (CET)
Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay1.nic.fr (Postfix) with ESMTP id 653594C0036 for <dns-privacy@ietf.org>; Tue, 15 Mar 2016 15:23:40 +0100 (CET)
Date: Tue, 15 Mar 2016 15:23:40 +0100
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: dns-privacy@ietf.org
Message-ID: <20160315142340.GA27831@nic.fr>
References: <20160315035859.11533.34536.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20160315035859.11533.34536.idtracker@ietfa.amsl.com>
X-Operating-System: Debian GNU/Linux stretch/sid
X-Kernel: Linux 4.3.0-1-686-pae i686
X-Charlie: Je suis Charlie
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dns-privacy/K_HtXL2mSyc5V6NiED-NbI47Om8>
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:24:29 -0000

On Mon, Mar 14, 2016 at 08:58:59PM -0700,
 Ben Campbell <ben@nostrum.com> wrote 
 a message of 54 lines which said:

> There seems to be a notable absence of a profile that requires
> server authentication but does not require pinning. I assume there's
> a good reason for that which is obvious to people with stronger TLS
> and/or DNS backgrounds than mine. But it might be helpful to say
> why.

I don't have a clear response here. Re-reading
draft-ietf-dprive-dns-over-tls-07, I find that the profile in 4.2 is
defined by a technique (pinning) not by its privacy properties. Is it
a good idea?

> Do (or should) the profiles have anything to say about clear-text
> fallback if a client cannot connect to the server's DNS-over-TLS
> port, or the TLS handshake fails? I infer that such fallback should
> not occur with the pinned profile, but what about the opportunistic
> profile?

I don't want to reopen discussions on
draft-ietf-dprive-dns-over-tls-07 but may be we can improve it for
draft-ietf-dprive-dtls-and-tls-profiles-00: its definition in section
5 does not address this issue. May be have two opportunistic
profiles, one with fallback to clear text if necessary and another
without?