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

"Martin Thomson" <mt@lowentropy.net> Thu, 04 April 2019 15:15 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 71FE91201D4 for <doh@ietfa.amsl.com>; Thu, 4 Apr 2019 08:15:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, URIBL_BLOCKED=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=Cm5kssCj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=06bmUcsA
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 lCOYMD-p24Hn for <doh@ietfa.amsl.com>; Thu, 4 Apr 2019 08:15:43 -0700 (PDT)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E3391200B5 for <doh@ietf.org>; Thu, 4 Apr 2019 08:15:43 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id E3FCA626A; Thu, 4 Apr 2019 11:15:41 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 04 Apr 2019 11:15:42 -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 :cc:subject:content-type; s=fm1; bh=3eCU350AjWP+spBEy0KxBnCKhoa0 wfhPBDnJKn98BRI=; b=Cm5kssCj2xUcw4J9yJsiMpcOqB4ANEvDAFxdzgYuEwBY KutJLe4e4aULwECDeis8S8o9lhAIJiBJFE4RC5vPMi7AkO9Q+rhixVzE7smISj30 8LQNZNiR/aRC/FHIIeXYnf8jL8AIAt6jbjKtMfZeZmm/qTGqpFum19g9KkgI+Iz1 XdxO2e1Wy+KJJFcAafbQqvs4/CdxU1QBo0YC1K57hmLitd/7WErPNWYnGAYz2F/5 YQNV13Dm7rHsK0TLhJGfmjuD66R3ldA/+uLh1OciJ9oYeYgb3wCZiVK9PKaLzH9W d8oa7csjbQyWQxurJgX/2qZ2G9jmQYSo6iZOc5McYg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=3eCU35 0AjWP+spBEy0KxBnCKhoa0wfhPBDnJKn98BRI=; b=06bmUcsAjIE/JkQWeECb1O EgKPwkT7n6Sl1uSzDeI7BQKCkptmLMkSp/qXWivILGsSDh+Uwq2zNol4CCdbSI3p CSh+gEVnukLc5wYByVyK+Bieh7iBWXC4Ije8USi2CudstJxyhCxxo+Q0hs3TO0Fo C0PXgkZlcmwmIR3/qQ5lwzVMYTAWxJWWg0Ibem+fYbPEgx+2zCvRXX9/CrH+UfLj IF+nPHfq4/x4OTQ6vzYw3dy5TQqSaOIBN3ptnbSor3f025gh5mKnjJISmywrx3YQ ieiclLAn23SoaPTVwLAH8ujWLKUOPHNE5zeOES3tMfo2I38nDXcZUA3B5JK0SY9A ==
X-ME-Sender: <xms:nB-mXCi7GUISeYQC54JdWev-zxXFqYCzr7Gs7aJDHO03BtvyWdhm9g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrtdehgdekheculddtuddrgedutddrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfgg fkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhm shhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehivg htfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhp hidrnhgvthenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:nB-mXJvWtR4US7UQNV8d0X8ycEoMYsg0zZ_OVBcuOq-DVUQtKmBhhw> <xmx:nB-mXLatpV-RKTTUqBLEzjn3VqDC0_x3v8ZjIyMWtCtWDauxouAjqg> <xmx:nB-mXBJKbDswqTO3c45Pr3LXliicml_XrIzs2juOpkA1oPg5YBhvHQ> <xmx:nR-mXJWXDNedNJNzsLc7BXTq8LD6NAX3d-PtoIO42gDkYrKfTZhlQg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3FB627C411; Thu, 4 Apr 2019 11:15:40 -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: <bfcd8de8-6442-4882-9bee-148db77809a3@www.fastmail.com>
In-Reply-To: <CAHbrMsB3J7G+h8ZA5_j+TPLsdLTpVJtmnUd3JiicXz4s7Wp+ig@mail.gmail.com>
References: <155341529409.18062.10657099011172813446@ietfa.amsl.com> <20190325110136.GA23793@laperouse.bortzmeyer.org> <08BD5718-CD1F-47B3-A4FB-4040F8E9FC4B@icann.org> <6121981d-9827-483d-92db-14bd8e39c05e@www.fastmail.com> <CAHbrMsB3J7G+h8ZA5_j+TPLsdLTpVJtmnUd3JiicXz4s7Wp+ig@mail.gmail.com>
Date: Thu, 04 Apr 2019 11:15:41 -0400
From: "Martin Thomson" <mt@lowentropy.net>
To: "Ben Schwartz" <bemasc@google.com>
Cc: "DoH WG" <doh@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/I43foVYzUULmRzmRScZt7Eh1vCs>
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: Thu, 04 Apr 2019 15:15:46 -0000

On Mon, Apr 1, 2019, at 23:23, Ben Schwartz wrote:
> What is your view on subsequent unauthenticated connections that _do_ 
> terminate inside the network? If these are allowed, then we can 
> consider designs that reduce the need for clients to perform 
> authentication, and move the point of authentication to a relay or 
> reverse-proxy operated by the network operator.

How do you determine that a connection terminates inside the network?  My assumption here is that discovery (DHCP/RA) is privileged, but nothing else.

As for avoiding authentication, I will suggest that is a non-goal.  We want consistent use of the protocol (be it DoT or DoH).

> For clarity, this is the DoT Opportunistic Privacy Profile in RFC 7858 
> Section 4.1 <https://tools.ietf.org/html/rfc7858#section-4.1>. It's the 
> default mode on Android 9 and later.

Right.  Forgive my sloppy non-use of the correct terminology.
 
> How would you view an arrangement where the network operator runs a DoT 
> forwarder at an RFC 1918 address with a self-signed certificate, 
> forwarding all queries to an external DoT resolver that the forwarder 
> authenticates by name against a typical root store?

All I care about is what the client can verify.  A self-signed certificate wouldn't work.  The forwarder could operate at the TCP layer and this would be fine, but clients can't trust the forwarder to do the right thing and just assert that without proof.  What you describe is a MitM attack.

We could talk about the use of an HTTP forward proxy for this, if the networking layer required that, but that is a lot harder to get right.  Then you could talk DoH or even DoT to the real resolver, but you would still have a TLS connection to a server with a valid name.