Re: [dns-privacy] Benjamin Kaduk's Discuss on draft-ietf-dprive-xfr-over-tls-11: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Wed, 19 May 2021 03:08 UTC

Return-Path: <kaduk@mit.edu>
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 CED953A1B15; Tue, 18 May 2021 20:08:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level:
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 IuuH1PLd-l5d; Tue, 18 May 2021 20:08:27 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 1F6673A1B2A; Tue, 18 May 2021 20:08:26 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 14J38Ila031491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 May 2021 23:08:23 -0400
Date: Tue, 18 May 2021 20:08:18 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Sara Dickinson <sara@sinodun.com>
Cc: Tim Wicinski <tjw.ietf@gmail.com>, DNS Privacy Working Group <dns-privacy@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-dprive-xfr-over-tls@ietf.org, dprive-chairs@ietf.org
Message-ID: <20210519030818.GH32395@kduck.mit.edu>
References: <162018984115.28455.12313533259326172808@ietfa.amsl.com> <E13CBD92-23F0-40EC-817B-833337491C8E@sinodun.com> <20210506021211.GF79563@kduck.mit.edu> <290A160B-8B4B-49BB-921A-AD3DC1804063@sinodun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <290A160B-8B4B-49BB-921A-AD3DC1804063@sinodun.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/NpRTs-Zf7cNTfMVK7olG8xE2YHM>
Subject: Re: [dns-privacy] Benjamin Kaduk's Discuss on draft-ietf-dprive-xfr-over-tls-11: (with DISCUSS and COMMENT)
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: Wed, 19 May 2021 03:08:41 -0000

Hi Sara,

On Thu, May 06, 2021 at 03:08:34PM +0100, Sara Dickinson wrote:
> 
> 
> > On 6 May 2021, at 03:12, Benjamin Kaduk <kaduk@MIT.EDU> wrote:
> > 
> > Hi Sara,
> > 
> > On Wed, May 05, 2021 at 04:09:55PM +0100, Sara Dickinson wrote:
> 
> Hi Ben, 
> 
> Thanks for the detailed response.
> 
> <snip to remaining issues>
> 
> > 
> >>> 
> >>> But, for concreteness: the text in Sections 8.4, 10.4, and 11 treat
> >>> cryptographic mTLS, TSIG, and SIG(0) authentication as providing an
> >>> equivalent level of protection to the (non-cryptographic) IP ACL.  My
> >>> understanding is that IETF consensus is to prefer cryptographic
> >>> mechanisms for authentication and authorization, when available.
> >> 
> >> That wasn’t the intention at all, and we are happy to add text to clarify that. 
> >> 
> >> To address this I would propose the following updates:
> >> 
> >> 
> >> Section 8.4:
> >> 
> >> OLD:
> >> "  o  the server MUST validate the client is authorized to request or
> >>     proxy a zone transfer by using one or both of the following:
> >> 
> >>     *  an IP based ACL (which can be either per-message or per-
> >>        connection)
> >> 
> >>     *  Mutual TLS (mTLS)
> >> 
> >> NEW
> >> 
> >> "  o  the server MUST validate the client is authorized to request or
> >>     proxy a zone transfer by using one or both of the following:
> >> 
> >>     *  Mutual TLS (mTLS)
> >> 
> >>     *  an IP based ACL (which can be either per-message or per-
> >>        connection)
> >> 
> >> If only one method is selected then mTLS is preferred because it provides strong cryptographic protection."
> >> 
> > 
> > I think in some sense even being listed as sibling bullet points can imply
> > "equivalent" for some readers, and accordingly this is not what I see as an
> > ideal change.  But the new text does acknowledge the qualitative difference
> > and is something I would be able to accept, even if it is not my most
> > preferred outcome.
> 
> One option here is to update the second bullet point to be a combination of IP ACL + TSIG to provide additional protection. As mentioned, this is what is done in practice today by anyone who wants to control TCP zone transfers. TSIG was earlier discounted as a standalone option (see my comment below) and with hindsight I’m surprised we didn’t propose the combination instead. 

The combination does seem much more powerful than either alone.  I'd be
happy to see that change, if there's support from the WG for it.

In light of the other topic (below), do we want to consider reformulating
the requirement along the lines of "MUST validate the client is authorized
to request or proxy a zone transfer.  The following methods are deemed
sufficient, and implementations may also use other methods that provide
equivalent or better protection"?

> <snip>
> 
> >>> 
> >>> Relatedly, the text in Section 8.4 says that TSIG/SIG(0) are "not
> >>> sufficient to authenticate the client or server", which is technically
> >>> true, but also seems misleading.  In XFR scenarios it's not clear that
> >>> specific identification (authentication) of the counterparty is
> >>> necessary for secure operation, if authorization to receive/send the
> >>> zone can be established without specific identification.  My
> >>> undersatnding is that, when combined with a strict TLS profile for
> >>> server authentication and appropriate trust policy on TLS clients, TSIG
> >>> and SIG(0) both serve to provide proof of authorization for the exchange
> >>> even though they only provide authentication in the form of group
> >>> membership (the relevant key material is typically available to multiple
> >>> machines).  As such, don't they provide strong enough cryptographic
> >>> protection (and end-to-end, no less!) to be a superior authorization
> >>> mechanism than an IP ACL?  (Any resulting text changes may bleed into
> >>> Sections 11 and 12 in addition to 8.4, per my COMMENT.)
> >> 
> >> So I _think_ your question here is why isn’t TSIG also considered a valid option in combination with Strict TLS?
> > 
> > Yes, that's a fair summary.
> > 
> >> The reason is that TSIG signed requests can be forwarded by a third
> >> party. The signature is ONLY over the DNS message payload, so it doesn’t
> >> cover the identity of the originator. That means that if only a TSIG is
> > 
> > Yes.  Part of my point is that the specific identity of the originator is
> > not always needed, if authorization to receive a transfer can be determined
> > without knowing the actual identity.
> > 
> >> required, the server cannot be sure that the client originating the TLS
> >> connection is not an on-path attacker forwarding requests, and therefore
> >> inspecting the zone transfer responses. (The real value of TSIG is that
> > 
> > Yes.  But in order to get into such an on-path position the attacker would
> > have to compromise the strict TLS required by the original client. An
> > attacker that can do that could also inject themself as on-path for a pure
> > mutual TLS solution.  In this sense we could consider that, when an
> > (authorized) client sends an XFR+TSIG to a proxy on a TLS connection where
> > strict server certificate validation has succeeded, the client is
> > delegating its authorization to receive the XFR to the proxy, and thus that
> > the proxy is also authorized to receive the transfer.
> 
> One concern is that an attack or misconfiguration that resulted in the client sending the XFR request in clear text would allow the attacker to obtain the signed message for replay. Since this is a migration from a clear text protocol to a TLS based protocol that doesn’t seem impossible. Whereas compromising mTLS directly is somewhat more challenging? 

It's a valid concern in migration scenarios, yes.

My preference (as always) would be to get some text in the document that
covers the properties that TSIG+strict-TLS provide, as well as the
perception of risk in the migration scenario that TISG migh be sent without
(strict) TLS and the consequences should that happen.  That would be
useful, IMO, regardless of whether it ends up being a recommended/permitted
option or not.  I am sensitive to concerns about adding a lot of new text
at a late stage without sufficient review, though, so I will ask if you
think we can come up with such text and get it reviewed or not.

> > 
> > TSIG of course does allow more than one proxy in a chaing, which does
> > introduce questions of transitive trust, but I believe that an attacker
> > that is capable of compromising strict TLS + TSIG is also capable of
> > compromising mutual TLS.
> 
> And also, because such an clear text message could be sent anywhere along that chain it seemed to exacerbate the problem...

Yes, that's the "transative trust" issue, where you have to trust everyone
in the path to behave properly and not fall back to cleartext.  There's not
really a good answer for that, which is why end-to-end protections get a
lot of attention...

Thanks,

Ben