Re: [Resolverless-dns] Paper on Resolver-less DNS

Joe Abley <jabley@hopcount.ca> Thu, 15 August 2019 16:54 UTC

Return-Path: <jabley@hopcount.ca>
X-Original-To: resolverless-dns@ietfa.amsl.com
Delivered-To: resolverless-dns@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019E71200D5 for <resolverless-dns@ietfa.amsl.com>; Thu, 15 Aug 2019 09:54:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 nmoKP5nOdcUJ for <resolverless-dns@ietfa.amsl.com>; Thu, 15 Aug 2019 09:54:06 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 18F85120074 for <resolverless-dns@ietf.org>; Thu, 15 Aug 2019 09:54:06 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id i22so470743ioh.2 for <resolverless-dns@ietf.org>; Thu, 15 Aug 2019 09:54:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=YMDbbvt1I6bjY1XZhn9ZhNoVD052D77caTGDmg7UUW8=; b=cDSDJ1mN+pkrc+HUfZZUBhDVq/T/iv6z5QEclanr+mhJGbj0r4JERezifMEE/sxE6n 4Q+Y+3qgnrkJ1APzyvb1yriDg3B+v+kSjBi82Ia7IlXKxhAPv95UWIwYtuJD/7feOMiu 9v5JCRfvFofA2Q12P9+z7YFSeD16bYioxarSs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=YMDbbvt1I6bjY1XZhn9ZhNoVD052D77caTGDmg7UUW8=; b=d5FjseTfe5aLRB5DIG5AjbMekWMTu6kVwCFNfKf7wNN83b4F9z9hglT1EXZskXG3/E VbtxNmnIQSH0EdfHVP4IXeLOv6bGVdz8dhNs1T/5zKKj78IZMOBsASpos7FlfMv8RMm8 O269GW2givHfPRqR7eZpntYSd1G+lY/i3CVi+wl61OyO+GXOGb+y085gla8WbTlBUhYM WbL59rGXYfRubp6Sr65tX3MXi1xUOjtzEVrPKUC2XCaZsdksBZbcIaJ0lR7gXrjxc30l nbyS+8kl+hWQpn0PSIGIj5HbrV8vvk9KZqlKa88RpRafZHeiOwKIqj9wNAV7TpLIpMLx wg1g==
X-Gm-Message-State: APjAAAVmKnfEAB8yA0N9hTUfIsKLhFp6UwEh2ncqmi8EhYi0uEUi3UIW qQ6MyYQjuHQbc/MduKr8ezfx7w==
X-Google-Smtp-Source: APXvYqwf8eAp48XHkjDLB7P8dghDUvVi+4wO+oVunuU44cE4FOBDqXEHqEd51oicLqac/tx0QszDqQ==
X-Received: by 2002:a02:bb8c:: with SMTP id g12mr3065021jan.116.1565888045110; Thu, 15 Aug 2019 09:54:05 -0700 (PDT)
Received: from ?IPv6:2607:f2c0:e786:128f:e4d3:9643:614c:849e? ([2607:f2c0:e786:128f:e4d3:9643:614c:849e]) by smtp.gmail.com with ESMTPSA id r7sm2490632ioa.71.2019.08.15.09.54.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Aug 2019 09:54:04 -0700 (PDT)
From: Joe Abley <jabley@hopcount.ca>
Message-Id: <CD27239E-55D8-45AB-9896-179D95BEDC9D@hopcount.ca>
Content-Type: multipart/signed; boundary="Apple-Mail=_E58B2E4D-67BB-4388-9F31-C96D3FB0E503"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 15 Aug 2019 12:54:01 -0400
In-Reply-To: <20190815163938.CF9CB85D108@ary.local>
Cc: resolverless-dns@ietf.org, bemasc@google.com
To: John Levine <johnl@taugh.com>
References: <20190815163938.CF9CB85D108@ary.local>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/ikhZWJgRryXMJaqULN5n6jC-Syg>
Subject: Re: [Resolverless-dns] Paper on Resolver-less DNS
X-BeenThere: resolverless-dns@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Resolverless DNS <resolverless-dns.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/resolverless-dns>, <mailto:resolverless-dns-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/resolverless-dns/>
List-Post: <mailto:resolverless-dns@ietf.org>
List-Help: <mailto:resolverless-dns-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/resolverless-dns>, <mailto:resolverless-dns-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Aug 2019 16:54:10 -0000

Hi John,

On 15 Aug 2019, at 12:39, John Levine <johnl@taugh.com>; wrote:

> In article <CAHbrMsBhR1yaLxQk7wZk54Jdf5nvkS03KC3UTae0Famu2+SV8g@mail.gmail.com>; you write:
>> -=-=-=-=-=-
>> -=-=-=-=-=-
>> 
>> Thanks for conducting this investigation, Erik!
>> 
>> In my view, the two main concerns with resolverless architectures have been
>> (1) simplifying stolen key attacks and (2) potential interference with
>> DNS-based load balancing.
> 
> I also like the paper but it misses the largest concern with
> resolverless DNS: it circumvents DNS based access controls.

This is an area where applicability is important, I think. I suggested splitting the problem space once before into phases (the message I sent seems not to be in the add list archive, so no link, but copy below). In that crude taxonomy, DNS-based access control seems applicable to the initialisation phase but not so much to the established phase.

If we can assume for the sake of this topic that there is a security model that makes sense that constrains what DNS data could be exchanged between server and client within an HTTPS bundle, and if access control was already exercised during the initialisation phase, perhaps it's not needed in the established phase. In that case, in that phase, resolverless DNS might be a perfectly reasonable and uncontentious choice.


Joe

> Begin forwarded message:
> 
> From: Joe Abley <jabley@hopcount.ca>;
> Subject: lifecycle of an engagement between an application and a service
> Date: 9 April 2019 at 10:26:22 EDT
> To: add@ietf.org
> 
> Hi all,
> 
> Vittorio and Stephen reminded me of some handwaving I inflicted on various people in the Hilton bar in Prague. Perhaps now is the time to widen the circle of injury.
> 
> Consider an end-user who wants to use some service over the Internet. I'll suggest we can consider the overall engagement between the end-user and the service in terms of a number of phases, each of which has some characteristics that are usefully different from others. My intent is to see whether we can reduce the scope of the problem from "all resolution in the world, ever" to something smaller.
> 
> For example, in the taxonomy below, I think we are mainly arguing about mechanisms within the initialisation phase. I speculate about different name resolution protocols being architecturally viable in the following established phase.
> 
> -- Initialisation Phase --
> 
> The end-user uses an application to begin a session with some service or other. Unless the addresses of the relevant service endpoints in the network are hard-coded into the application (in which case stern frowny-face) this will involve some name resolution.
> 
> For popular services today that name resolution often involves enterprise DNS services who generate responses based on a set of criteria specified by the service provider, e.g. the (city, provider) pair that the DNS provider guesses corresponds to the end-user, based on things like the EDNS(0) client-subnet option, the address of the resolver, etc. This process involves approximations and assumptions. The QNAMEs are generally generic (e.g. they are bigservice.org <http://bigservice.org/>;, not user-specific-random-label.bigservice.org <http://user-specific-random-label.bigservice.org/>).
> 
> The end-user uses a resolver that has been provided as part of the process of joining the local network, or one that has been hand-configured by the end-user, or one that is specified by the vendor of the application.
> 
> The result of the resolution process is a set of one or more initial service endpoints, layer-3 addresses. The application stands up one or more transport layer sessions to those initial service endpoints. Those transport layer sessions often incorporate some end-point authentication (e.g. a bundle of TLS sessions with some appropriate certificate validation process).
> 
> The control point whereby someone (e.g. a resolver operator, an on-path network operator) can prevent the application from communicating with the service by DNS name exists within this phase. The choice of name resolution mechanism in this phase is hence contentious.
> 
> The control point whereby an on-path network operator can prevent the application from communicating with the service by layer-3 address exists within this phase. This is potentially independent of the choice of name resolution protocol or transport.
> 
> There is potential for metadata surveillance during this phase -- the fact that an application located at one address is attempting to initialise a service using a particular DNS name. This is a potential privacy concern. There is potentially a similar risk based on layer-3 address which is independent of name resolution.
> 
> -- Established Phase --
> 
> The application begins to communicate with the service end-points.
> 
> Additional name resolution may well occur during this phase since popular services are distributed, network performance and topology is dynamic and end-users are mobile. The QNAMEs involved might be user-specific and designed to trigger cache-misses (e.g. incorporating pseudo-random 64-character labels), e.g. because there is some user-specific behaviour that is incorporating the resolution process as a communications channel, or for reasons of traffic-engineering as described in the enterprise DNS commentary above, or because it's more reliable than using low TTLs, or something like that.
> 
> By the time an application's engagement with a service enters this phase, the opportunity to block the engagement has passed. The nature of the name resolution that exists within this phase is therefore potentially less contentious than in the initialisation phase. The communications channels between the application and the service endpoint have been authenticated at this point, and so to some degree the same trust that the application puts in those channels for other objects might also apply to name resolution.
> 
> As a thought experiment, perhaps a particular web service is easier to manage if all the resolution in the established phase happens inside the same HTTPS bundle that carries HTML and other objects; performance measurements executed in javascript in a browser could be shared with the service provider which could then push user-specific names to optimise service performance and that process might be architecturally cleaner and cheaper than using the more circuitous approach necessary with enterprise DNS services. The control points mentioned in the initialisation phase are unavailable in this case, but perhaps that's ok.
> 
> Even without such sophisticated resolution requirements, making the service provider directly responsible for the name resolution involved in using their service eliminates some attack vectors, e.g. the chance that some required resolution in this established phase might be hijacked by a third party as part of a phishing attack.
> 
> -- Termination Phase --
> 
> For many web services this seems like it is probably a noop, but it seems wrong not to include it by way of acknowledging that all good things must surely end.
> 
> 
> Joe