Re: [dns-privacy] I-D Action: draft-ietf-dprive-xfr-over-tls-02.txt

Tony Finch <dot@dotat.at> Fri, 31 July 2020 01:06 UTC

Return-Path: <dot@dotat.at>
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 A97173A03ED for <dns-privacy@ietfa.amsl.com>; Thu, 30 Jul 2020 18:06:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=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 l6OjasiTWMMg for <dns-privacy@ietfa.amsl.com>; Thu, 30 Jul 2020 18:06:31 -0700 (PDT)
Received: from ppsw-43.csi.cam.ac.uk (ppsw-43.csi.cam.ac.uk [131.111.8.143]) (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 0F9D33A0303 for <dns-privacy@ietf.org>; Thu, 30 Jul 2020 18:06:30 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:47214) by ppsw-43.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1k1JVE-000efT-o3 (Exim 4.92.3) (return-path <dot@dotat.at>); Fri, 31 Jul 2020 02:06:28 +0100
Date: Fri, 31 Jul 2020 02:06:28 +0100
From: Tony Finch <dot@dotat.at>
To: Sara Dickinson <sara@sinodun.com>
cc: DNS Privacy Working Group <dns-privacy@ietf.org>
In-Reply-To: <390A1620-3F46-4611-BBE9-6B9013FB017C@sinodun.com>
Message-ID: <alpine.DEB.2.20.2007310143180.16320@grey.csi.cam.ac.uk>
References: <159465861212.27789.12532144774876250909@ietfa.amsl.com> <A0F13E92-889B-415A-BFA1-215838EE895D@sinodun.com> <alpine.DEB.2.20.2007132101010.32181@grey.csi.cam.ac.uk> <390A1620-3F46-4611-BBE9-6B9013FB017C@sinodun.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="1870870841-50207548-1596157479=:16320"
Content-ID: <alpine.DEB.2.20.2007310205530.16320@grey.csi.cam.ac.uk>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/gW5EwJcIghxKNCdLax9KsuMTjEM>
Subject: Re: [dns-privacy] I-D Action: draft-ietf-dprive-xfr-over-tls-02.txt
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 31 Jul 2020 01:06:33 -0000

Sara Dickinson <sara@sinodun.com> wrote:
> > On 13 Jul 2020, at 23:35, Tony Finch <dot@dotat.at> wrote:
> >
> > 7 authentication
>
> Belated responses on this topic!

And a few more thoughts from me, pruned for length ...

> Well the goal was to compare and contrast the set of existing control
> methods - they do all have different properties and we wanted to explain
> where TLS fits in with these and be clear it can’t directly replace
> them…
>
> Perhaps authentication is too broad a term for this whole set of
> mechanisms. Maybe the split here should be transport independent
> verification mechanisms vs TLS…?

What I would expect to get from reading this section is how TSIG and X.509
authentication interact (and maybe SIG(0) too), i.e. what the implications
are for configuring server ACLs and client credentials.

ZONEMD doesn't fit in that context, I think.

> We use a v. broad definition of ‘data auth’:  “Authentication that the
> DNS message data is signed by the party with whom credentials were
> shared”, but given your comment I believe better term would be something
> like ‘data origin auth’ or ’transfer entity auth'.

Right, that's the distinction I was making. But I think this draft only
needs to care about the peer authentication because data authentication is
unaffected by TLS. (And doesn't affect privacy.)

> TSIG gives entity authentication but not guaranteed confidentiality. The
> specific threat here is that in principle without authentication a MitM
> attack is possible on the TLS connection….. that attack can see not only
> the zone transfer requests but more importantly the responses, which is
> what we are trying to avoid.

Ah, I understand now, thanks. Given that I think you are right to leave
out unauthenticated-but-required TLS as an option since it doesn't make
much sense. I have not read RFC 8310 properly yet, but if it doesn't
discuss why this middle option doesn't provide much extra privacy, then
perhaps this draft should have a few words.

Otherwise, it all sounds good. Thanks for working on this draft!

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
South Utsire: Northwest 4 or 5, becoming variable 3, then southeast 5 or 6
later. Slight or moderate. Fair. Good.