IETF Logo Mail Archive

[Doh] A question of trust (was Re: Draft -09 and WGLC #2)

Martin Thomson <martin.thomson@gmail.com> Tue, 29 May 2018 00:23 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72FAC12421A for <doh@ietfa.amsl.com>; Mon, 28 May 2018 17:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=gmail.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 7_UZJyQJPPJ0 for <doh@ietfa.amsl.com>; Mon, 28 May 2018 17:23:38 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 83D371270B4 for <doh@ietf.org>; Mon, 28 May 2018 17:23:38 -0700 (PDT)
Received: by mail-oi0-x230.google.com with SMTP id b130-v6so11550299oif.12 for <doh@ietf.org>; Mon, 28 May 2018 17:23:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rzRhZU9hdXYLgu1GcXXoeS3TNAE+m6HDKKwoqpC0aJE=; b=X9MyF6ZI3WKBUIjbxpvH8DQVt95sLNqD/kdwgsNb7vl8U5ARgprodxXsF133QqTPyz zvpjxz0MlHpM96pbgcB+0mYukcyDpuE0io018eRHr3Neq9cvb6JPGfnhiWCEQdOM8ldn Qp69kKd9muFNncqmIzsWDengAjL5V2iwguNOTbgB921X/rR2zKu93q4/HhadhmxtB2mB iorAdajwjLBEZtmGDTUmqQvOx45oa81jEOW313jy6ikaM9WqionCKz6QXsTDKT66TOfc dq4eh9WtS4L+C2e5dedvJE8fe9DkG1SpitxsUBgJGTlnV+AJ3loNRoN8O9U1JzjrhkvO oGOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rzRhZU9hdXYLgu1GcXXoeS3TNAE+m6HDKKwoqpC0aJE=; b=faJdD0/b2tFrx6nPFDfZ//nBEfHYYdmyDgqL7Au8I9Vi8GXw1S/QyJMoKbWqdsmKh3 SgzPnGzw9iRDVp2hlBH21RJ9r+3gAGtvZK945Q9QV7jJn5tU04jCHp3APOf/OITzS7jz Xh0DI+3QwG/zu4fno+8q/0pfZaG2Un41lPG2S/o+oqWVhbpeau/ch1NTkyU7IUsreQqn ipcnXioPkFB/cIuy/bXXOk+H8kWF/K7TGHI8AB8Nlqdk3TRkX9oFLGXxilGdkqzq5mkg Ia1WbkgmBtc+FuVTVm7ZtcV6S+V5zTZl41n8M8I1uMqG653+hEoA8gLFJdxOG0Dvc4U5 DBIA==
X-Gm-Message-State: ALKqPwf3Arb5qQwKs7TVPzxiVlNFczhtbWjecZ7Wy8MzCWxhnNgfmRu1 bERt2pg27BDO1bq0WLeY5GAxUaYcLtN2IE+Nqaqdea9a
X-Google-Smtp-Source: ADUXVKJgJPS0nte9vQ1Y41pkiDNxVxzzSg3spjSnEoEMu5psNAFutsAY3xHgh2Y3rINOcv6gdIulE/Lw3tPyw/NT0OA=
X-Received: by 2002:aca:4e15:: with SMTP id c21-v6mr7957893oib.254.1527553417566; Mon, 28 May 2018 17:23:37 -0700 (PDT)
MIME-Version: 1.0
References: <CAHbrMsCxkogJ-fzubf7cPgvbeGAhWUFKV3crrmn4ee6=fDnqwQ@mail.gmail.com> <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> <CAOdDvNrpLwF5jpn1YA4-HXsfGxVkdds+xHVd6Bxy0Ux+3nrcrA@mail.gmail.com> <CA9BEE64-9F16-4CCC-A1E0-4C7FD45C455C@icann.org> <20180528161043.GB12038@mx4.yitter.info>
In-Reply-To: <20180528161043.GB12038@mx4.yitter.info>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 29 May 2018 10:23:27 +1000
Message-ID: <CABkgnnV3kKFCzKLfPf_0WZh95jr2vEt652Rb4EozfqROCVsJdA@mail.gmail.com>
To: DoH WG <doh@ietf.org>
Cc: Andrew Sullivan <ajs@anvilwalrusden.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/JdS5GAHav-DyM6w6cxf_Saljdvo>
Subject: [Doh] A question of trust (was Re: Draft -09 and WGLC #2)
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 May 2018 00:23:40 -0000

On Tue, May 29, 2018 at 2:10 AM Andrew Sullivan <ajs@anvilwalrusden.com>
wrote:
> This bit in section 4 strikes me as strange:

>      A client MUST NOT use a DNS API
>     server simply because it was discovered, or because the client was
>     told to use the DNS API server by an untrusted party.

> This feels like it's crying out for a definition of "trusted", and yet
> that seems to me like a bad idea.  Today, when you use an open wifi,
> you probably don't actually _trust_ the network operator, but you
> accept the default DNS server you get from DHCP anyway (unless you're
> the sort of nerd who thinks about this sort of thing).  I can't tell
> from the text whether that kind of "trust" is supposed to be permitted
> by this or not.  I recall some discussion about this in the past, but
> if the WG thinks that was resolved the resolution is totally opaque to
> an uninformed reader.

Thanks to Andrew for highlighting this little piece.  His comment
emphasizes the problem we're having here.  And there has been a lot of
back-and-forth on this subject.  I suspect that we might have to tackle the
"trust" question to make progress here.

I've always been unhappy with this text, but understand that the text
exists because other people are nervous about having arbitrary servers
provide DNS responses.  But as Andrew observes, that is precisely what
happens in a lot of scenarios.  Let's not pretend that the tiny few who
override DNS configuration are relevant here; those people are best
accommodated better with specific configuration options that control
defaults.

That's why I originally proposed a change to use "authorization" rather
than trust.  That is, it does not imply a value judgment.  But that's not
getting at the crux of the matter either.

The problem with accepting arbitrary DNS answers is grounded in two pieces
of trust that clients confer on servers:

The first is that stub resolvers frequently offload DNSSEC processing,
relying instead on the AD bit.  Such a resolver is entirely at the mercy of
the DNS API server in this case for answers that might be DNSSEC
authenticated.  That implies a degree of authorization.

The second is that DNSSEC doesn't secure the protocol completely.  DNSSEC
allows for multiple valid answers for a query and the choice of answer can
be important.  DNS-based load balancing uses this, and performance and
security can depend on the answer being selected correctly (at least in the
aggregate).  Here, there's a degree of authorization involved: we assume
that a client picks a server that forwards queries and answers faithfully.

On this latter point, there's a consideration that might be more pertinent:
we assume that the client directs queries to the same server and thereby
gains a consistent set of answers over time.

If we change the text, I think that we could avoid the MUST and say that
this document assumes that DNS API clients configure a single DNS API
server and do not send queries to, or accept answers from, other servers.
Then explain the consequences of configuring a DNS API server in terms of
what "trust" is conferred to that server, as I described above.  That is,
no 2119 language, but more along the lines of an applicability statement;
making it clear that the use of any other style of configuration is not
advisable, or at least making the risks known.

v2.23.0 | Report a Bug | By Email