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

Ben Schwartz <bemasc@google.com> Mon, 01 April 2019 21:23 UTC

Return-Path: <bemasc@google.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 E514612000E for <doh@ietfa.amsl.com>; Mon, 1 Apr 2019 14:23:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 RvLlKrPwy5pP for <doh@ietfa.amsl.com>; Mon, 1 Apr 2019 14:23:55 -0700 (PDT)
Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 0019F120114 for <doh@ietf.org>; Mon, 1 Apr 2019 14:23:54 -0700 (PDT)
Received: by mail-vs1-xe36.google.com with SMTP id t78so6480463vsc.1 for <doh@ietf.org>; Mon, 01 Apr 2019 14:23:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wr9sXpzVM8zLEjFiHkhOLSFQkSHPk7syWmIuK9rTKhk=; b=bOQsIgEvZNudY6jlPbouIZ9LheOYPzKggUpEX55h09fxLvXGPYGqVlBSMOgZozA/7O +Cx6elYgZl9fTwd2APGBhj920j9U96VOhjb3mrb/vPBrPfRlwmn3Mqd5sI9iVkfmVor6 yyv+FHenr8/FBOlZ672Rb2EHD5bVPa0B6C9fMaaBm56c+t/+UnZespVVqtOdG7+zaiSe zmNMcvc130mKR5nvRRJX7QvWuSzLlXGxGW73/KqK5Cg27hqukgH4jm4tx3OO2Kj8WG/Z BGvnn7brJxuqHk4ybMlJZwMl5VKcye98FjS8QjJCOAJSMer/fyMZXt9KsT6thQammoaa TBGw==
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=wr9sXpzVM8zLEjFiHkhOLSFQkSHPk7syWmIuK9rTKhk=; b=j2x9tkR4o3U1vyJf3OM0uwA+cAu9bhXcJFubog5AHd0CRwKOlMKTGYeAmRrk/EWS2J Hch2A6no/eqzsMitDmVYsSpR4NVlDNYfGYxruvJ/kh67BbGmKeilCpx68JKoNpHcEzzd stpRhW3ftcUdxVWfTAXVf+g5/mvptu46UceAfrgkEBGWXfwMADLIKfYgQp4Ga4NO8d3E ZMnYsbmar59Rj3KV7BZm3JG/84EyjFR8iTLsReDjXmH/iX4n9qiUxssNsFMVo8lUG0OR KpHcvUoA5uNr97BGpi/StbjoXFCiTcGr6O79dbmIxe6ploXnnxs0QAEV66FpuaKEUl2N dgsA==
X-Gm-Message-State: APjAAAWVPcfqzRte6W16YFz8nFizghD+iiiX54nZp+RqhrvnzPP91lnP Ck2UiCkToDkZSzqCorpG6xuM4vqcB4NoeuDoGLG2jXmrjGw=
X-Google-Smtp-Source: APXvYqxrFs+u7QLSddpsKoYG5fWL32FIZ/T71bo8NVw5WgA1HHaoUrvLRAkpWzNe8GMraX/8cX6+3sk5QSvHGZeDDOE=
X-Received: by 2002:a67:fb89:: with SMTP id n9mr24449349vsr.119.1554153833692; Mon, 01 Apr 2019 14:23:53 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <6121981d-9827-483d-92db-14bd8e39c05e@www.fastmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Mon, 1 Apr 2019 17:23:42 -0400
Message-ID: <CAHbrMsB3J7G+h8ZA5_j+TPLsdLTpVJtmnUd3JiicXz4s7Wp+ig@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: DoH WG <doh@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000035cf9005857ea358"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/5kB8VWuS2hVjfQeP73_0fYXgxHE>
Subject: Re: [Doh] Authentication in draft-ietf-doh-resolver-associated-doh-03.txt
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: Mon, 01 Apr 2019 21:23:58 -0000

On Sat, Mar 30, 2019 at 8:48 AM Martin Thomson <mt@lowentropy.net> wrote:

> 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.
>

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.


> 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.)
>

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.

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?

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.
>
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>