Re: [Doh] Authentication in draft-ietf-doh-resolver-associated-doh-03.txt

"Martin Thomson" <mt@lowentropy.net> Sat, 30 March 2019 12:48 UTC

Return-Path: <mt@lowentropy.net>
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 8D26B1201A4 for <doh@ietfa.amsl.com>; Sat, 30 Mar 2019 05:48:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=UxTBQ1aV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=7Og57Fnm
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 lKIh9Sx1u_uB for <doh@ietfa.amsl.com>; Sat, 30 Mar 2019 05:48:32 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B69D1201A3 for <doh@ietf.org>; Sat, 30 Mar 2019 05:48:32 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7814921ADD for <doh@ietf.org>; Sat, 30 Mar 2019 08:48:31 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Sat, 30 Mar 2019 08:48:31 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=HFyP7GOsN0Dptm0CCNy0bHTm5It+9FB oM0zPDNS+Mqg=; b=UxTBQ1aVwOGmzrzQpwlpmlxyT8KWoJRzGd391466dVgzkJ0 gwkJd6UeM1r0u4EdSejgWLXoc01fn4ZAGE35xtd3s3C868mOwq35760u8hrHcxah EaHEvjJZLovax6syiVNd06+55FdijNywjLg504QA6yHjGkkysGiilknUBaFaw919 4DmC6SdqSWmKnVmPjoizMDic4+ZcPzBMg3hJz5fS/JrswX04d50i79ZhZgtAmkzv QUbaVdUqoL9hOQcQ4Mm/exHGrEPiGKF8byvgujBym+zmtcW4jVzWlovP/ChRcKp1 nihYcz0nZ8eScmtFwDR1WMTaNAZiNJlNbk2MiHQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=HFyP7G OsN0Dptm0CCNy0bHTm5It+9FBoM0zPDNS+Mqg=; b=7Og57FnmVigMld9yygJ0J5 PyQFuSeiyWa02V362VFuMOz91uogTmmj4B77biM3AEQuyErjyK+S8lweXAouDUDv Hx4Q2GcAGfT3nKMb7Tn/3CwYPPHWzB2TTaYbtjrpTV8+7EYP4NFC3ueYqsFIv1v1 MpFsSI/UayuwpTf1NAKV437380cTrRv0yRLcr2Fk6s3PhKcmATbPeNAP5E2i0O33 SgP/i74qkC+ilTs+bNtw3KBgs/jH3zUitvz7vDtU9rVpQiJXtrCB2Jp6qK8ooEO7 ad97RYzc8qXWdFFLdzyGvNuQ/dzizNCMgjGRNDbyE6eH/rZ1IsmFQTVU3zD1NamA ==
X-ME-Sender: <xms:n2WfXM7sLw-3qL8ZpyUz_PQw5_pFvJeRqkF7o44v6hAV5_XlcaoKVQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrkeelgdegiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofi gvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:n2WfXJodn3RbrLN1Lvzz0Tv43EBOF76zc-ade2z9xhEdasd3BmHohQ> <xmx:n2WfXOPHvRHT44mM4QIAMdjhl0KJsIWS4mmV93VqxSuM2kEbA5-GMw> <xmx:n2WfXHIMjh5MlJ075RkQRuWALhhvO55KwViwHwVqYovMeW88m6eO0Q> <xmx:n2WfXGsa1HVKtgwcxQla9iWatHlljUkdHj1Q8P0l2OpQLR4GgaRrfA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0A64B7C1B7; Sat, 30 Mar 2019 08:48:31 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1
Mime-Version: 1.0
X-Me-Personality: 92534000
Message-Id: <6121981d-9827-483d-92db-14bd8e39c05e@www.fastmail.com>
In-Reply-To: <08BD5718-CD1F-47B3-A4FB-4040F8E9FC4B@icann.org>
References: <155341529409.18062.10657099011172813446@ietfa.amsl.com> <20190325110136.GA23793@laperouse.bortzmeyer.org> <08BD5718-CD1F-47B3-A4FB-4040F8E9FC4B@icann.org>
Date: Sat, 30 Mar 2019 08:48:32 -0400
From: "Martin Thomson" <mt@lowentropy.net>
To: doh@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/A2YthHjFwwwpC3d0MrOm1-syH48>
Subject: Re: [Doh] =?utf-8?q?Authentication_in_draft-ietf-doh-resolver-associ?= =?utf-8?q?ated-doh-03=2Etxt?=
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 30 Mar 2019 12:48:34 -0000

On Mon, Mar 25, 2019, at 12:37, Paul Hoffman wrote:
> The reason I didn't drop down to http: is that doing so evokes the 
> <horror> response, even though you are quite correct that the other two 
> methods given in this document do not offer any authentication. 

There is a different reason that I think is stronger.  We tolerate an exposure on DHCP and other network-layer configuration options (like the v6 RA).  The security implications of those mechanisms are well understood and it is common for networks to deploy systems that limit the opportunity for attacks.  Things like filtering broadcast and RA from end hosts are common.

But the connection to a resolver might be harder to secure in this fashion.  Though it might be possible to narrow the use of unicast port 53 (or 853), such filtering is different.  It is not always the case that the resolver is local in the same way that a DHCP server/relay or gateway is.  For DoH, which might use a service that is completely external to the network, this is more difficult.

Therefore, it is easier to look at this step of the configuration process as being subject to "untrusted" activity and insist on authentication.  It's certainly true that the only basis for authentication is the assertion by the network discovery phase, for which you have no prior expectations.   However, the property we are looking for is that we are talking to the same server that the network intended for us to talk to.  Thus, if the name of the server comes from the same mechanism that gave us an IP address (DHCP), or the system that provides connectivity (RA), then we at least have that much.

If your goal is to talk to the resolver provided by the network, then I believe that to be sufficient.

Hence I would propose a different design for this, bringing DoT into the design.

1. The first step requires no new protocol mechanisms.  To discover DoT, connect to the resolver IP at port 853.  If the server produces a certificate that is valid for the IP address of the resolver, then you are good to proceed.  No new mechanism is required.  (Clients may decide to accept any certificate here if they require opportunistic security, but I would suggest that this is unwise for the aforementioned reasons.  That said, it's better than using Do53, so I'd say it's still worth doing except for the fact that this establishes an expectation on the part of DoT resolvers that having a valid certificate is not required, which is dangerous.)

2. We add a field to DHCP and RA that carries the "DoT resolver".  When this is present, the client resolves this name using the resolver.  This resolution is unsecured.  The client then connects to the resulting IP address and validates the certificate it presents using this name.  This enables easier deployment of DoT because a certificate for a name is easier to get than an IP certificate (it also enables use of 1918 address and the like).

3. We add another field to DHCP and RA that carries the "DoH resolver".  When this is present, the client resolves the associated name using the unsecured resolver.  The client then connects to this endpoint, validates the certificate and proceeds to use DoH.

We could decide not to do the DoT step, but I wanted to include it to illustrate the symmetry of the design.

You will observe that this is significantly simpler than the proposed design.  There are several drawbacks, that I will address:

A. A client in a residential network will not receive this option unless their gateway/relay is configured to relay these values from external network.  The design proposed in the current draft has this property in that the SUDN is forwarded by resolvers that don't understand its purpose.  In this case, endpoints will talk to the DNS proxy in their gateway and not be able to discover a DoH service provided by an ISP.  RFC 5625 points out that it is not generally possible to talk to the external resolver. 

B. This doesn't provide any option for web clients to find the local resolver.  I will separately argue that this is not a valid use case, and moreover that it is one that presents some privacy challenges for clients and networks.  It should not be possible for a web site to be able to use a client's position in the network to access information that it would not otherwise be able to access itself.  Allowing requests to a local resolver might allow access to that sort of information.  Sites are better suited to making requests of configured resolvers.  With DoH, they can make those requests from the client, meaning that the answers will be more suitable for the client's position in the network than their own.  Though this requires that the configured resolver has nodes that are deployed near the client, I believe this to be sufficient.

I think that problem A is pretty significant.  The SUDN option does help there, but it eliminates the weak "authentication" we have.  For anything in this area to work, I think that we would need some other basis for deciding that the DoH server that is identified in this way is OK.  The only idea that I have, which is a poor one, is to configure clients with a list of "trusted" resolvers.  I don't like maintaining these sorts of lists, but it might be the only way to manage it.  No matter what option we choose here, I would prefer that we look at the DHCP/RA steps first.