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

Sara Dickinson <sara@sinodun.com> Mon, 27 July 2020 14:25 UTC

Return-Path: <sara@sinodun.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 7B91D3A1A11 for <dns-privacy@ietfa.amsl.com>; Mon, 27 Jul 2020 07:25:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sinodun.com
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 ocSujmVw31Z5 for <dns-privacy@ietfa.amsl.com>; Mon, 27 Jul 2020 07:25:33 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (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 764C23A1B10 for <dns-privacy@ietf.org>; Mon, 27 Jul 2020 07:24:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sinodun.com ; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=/SjvDAHxXo53Vww6xkYtDA8vufgJdrPE7uMuzpCTE7g=; b=eCy4jBr44xEoA13ZswILhVgOkD KkjwTbRSh93hQF32/lHD5nad+eJXFcnlaOq3sVb/MoKr8BQ3dMLCpPNoTNvH+gf6DNM5NJZ3Gf04v VBBzIAYotL2h7lahYmYtewE+9h6AaamgEDltm3lesDpmCfTn5aS5csT4BZD38cICsYRJoX2PFpHPo l8JDNowxqn8q1V9fMMRaR8nky1p92YFnZGIv6zYJ6kxKphnzijqrdyB7LqczjYIUw2gwqV1SqIHSM IHANZpExwYpH5YF79JFvfyH/4GcKhDt5/V2Q/XFLRVdBeRRqAMnJvfajE7pWORWx6kHcFlTI8A1lR EWnHNpnw==;
Received: from [62.232.251.194] (port=30197 helo=[172.27.240.4]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <sara@sinodun.com>) id 1k043f-00074g-SU; Mon, 27 Jul 2020 15:24:56 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\))
From: Sara Dickinson <sara@sinodun.com>
In-Reply-To: <alpine.DEB.2.20.2007132101010.32181@grey.csi.cam.ac.uk>
Date: Mon, 27 Jul 2020 15:24:47 +0100
Cc: DNS Privacy Working Group <dns-privacy@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <390A1620-3F46-4611-BBE9-6B9013FB017C@sinodun.com>
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>
To: Tony Finch <dot@dotat.at>
X-Mailer: Apple Mail (2.3445.104.15)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/rwz1u6k-J3nnn6P5A0Us_jrdzaQ>
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: Mon, 27 Jul 2020 14:25:36 -0000


> On 13 Jul 2020, at 23:35, Tony Finch <dot@dotat.at> wrote:
> 
> I've had a read through and here are a few, er, I mean several things that
> caught my eye:

> 
> 7 authentication

Belated responses on this topic!

> 
> It seems weird to mix up channel auth and data auth, since they are quite
> different things. As I understand it, ZONEMD isn't really authentication,
> it's just an integrity check (unless it is used in a signed zone). And if
> you are talking about data authentication it seems odd to leave out
> RRSIGs.

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…?

> 
> TSIG doesn't provide data authentication. It provides mutual
> authentication of the endpoints, and data integrity, but the server can
> lie to the client about the zone contents. (The server is not necessarily
> the ultimate authority for the zone.)

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

> 
> It would be useful to have terminology to distinguish between TLS where
> the client software tries on its own initiative, with fallback to TCP
> (which is what I think of when I read "opportunistic"); as opposed to TLS
> configured by the admin without fallback to TCP and without any client or
> server certificate auth. I'll call the latter "unauth”.

So here we were following the definitions of Strict and Opportunistic TLS from RFC8310 (in addition to mTLS) although I think this needs clarification in the text:

Strict is to use TLS _and_ the client authenticates the server or else hard fail
Opportunistic is try TLS with authentication,
   if not fallback to unauthenticated TLS
   if not fallback to TCP.

Only those two extremes were defined for stub to recursive… we could go for a finer grained model here if we think there are real uses cases for the intermediate state (your 'unauth’), I’m not convinced (see next point).

> 
> I don't think strict TLS + TSIG adds any benefits beyond unauth TLS +
> TSIG, because TSIG already provides mutual auth. Well, there's some risk
> that the client may send requests to the wrong server, which goes back to
> my section 4.3 question about whether it is part of the threat model to
> worry about exposing which zones a client holds.

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. 

> 
> Mutual TLS is roughly comparable to unauth TLS + TSIG, but it has the
> advantage that it's a bit easier to set up in a way that prevents clients
> from being able to impersonate the server. If you want to do this with
> TSIG then every client needs its own key, and the server config has to be
> updated whenever a client is provisioned or decommissioned. With mutual
> TLS the server only needs a relatively static CA cert that can
> authenticate any client cert.

Given the above I think it is reasonable to say it is roughly comparable to Strict TLS + TSIG if there are no proxies involved. Depends how easy you think setting up and distributing client certs is, which probably depends on if you run all the servers :-)

> 
> I think there should be something in the spec about how certificate
> subject names relate to how (in strict and mutual TLS) the client
> authenticates the server, and how (in mutual TLS) the server decides that
> the client's requests are authorized. I would like to be able to give my
> client a server name (and optional address) and have it authenticate the
> server using the system CA cert store and server certificate
> subjectAltNames. I would like to be able to give my server an ACL
> containing my private CA cert and a client cert subject name pattern.

We do reference RFC8310 which specifies how the client authenticates the server but perhaps the draft needs to be clearer in that we are suggesting exactly the same mechanism for XoT. 

Mutual TLS (if it stays in the draft) does need some more specification though….

Thanks again!

Sara.