Re: [dns-privacy] [EXTERNAL] Re: Review request: draft-btw-dprive-rfc8484-clarification

Ben Schwartz <bemasc@google.com> Fri, 11 September 2020 14:46 UTC

Return-Path: <bemasc@google.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849023A0A65 for <dns-privacy@ietfa.amsl.com>; Fri, 11 Sep 2020 07:46:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.6
X-Spam-Level:
X-Spam-Status: No, score=-17.6 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 JCG8TF6Pjvih for <dns-privacy@ietfa.amsl.com>; Fri, 11 Sep 2020 07:46:56 -0700 (PDT)
Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 F31123A0A64 for <dns-privacy@ietf.org>; Fri, 11 Sep 2020 07:46:55 -0700 (PDT)
Received: by mail-il1-x12a.google.com with SMTP id f82so4539076ilh.8 for <dns-privacy@ietf.org>; Fri, 11 Sep 2020 07:46:55 -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=HMeKTNrfrHy0Cy6wGb6WcBPAptMHaL2ISy94EPg4nKc=; b=CG+sFNQLM806sNA/YPPydHmUVOSiuscDTfMs0Y8+eXXFPifnj6mY0tQBFyw1LDq7B5 iUnOYn12iRIVb5BllkgugEtx/g7J5xSH7+TKJttzqLqRp7HUFzbGEia+0zABS1wuUnXn pEB66BbmkavRk/dsrjXZGM79Ig8AF2UWul7GRPVm1I22adnWiA4KIF8m9RwAQjsYXx/9 R4o87A5sQP+9MH5R4dzKjWHhYBGaiCJxpu9cCqDtzc0bV41EGutJa2D5bF0JvUQSWh4F KYEmt0JVVjcBIlNyX/yMR1XRL6hlFd63tkgRermuAVEvmDxziXmJ0SfkMYLXpuxRrizd EaIw==
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=HMeKTNrfrHy0Cy6wGb6WcBPAptMHaL2ISy94EPg4nKc=; b=CZfhAARZmoRYnnnod56asqFTlySSkVtZRWV3Hir4HPGG7OsBOcz5DwlEqKIf9nM5UY d+AjLXxGjqGWAkXbvOWi955FzeTSkj84/whlli7+lAruKdApVUwdQ37RCof113sVLiL1 w/XDf9nI+UV4IxSM8o8hgG+RtwFLmH3YxYA8Epe3rM/9Zk/1h1916UJrJAEGPDEM5UWM BTTkLXorc6swk8uHx6gmEXkaRKax3/hSrDJfH0luV8DeqPHhbSSj4oVi1OKoqhBKhFMv UJH33XTGxFIM6TemlDpc8ks/22dSZsbOGXSBNHGNhij3l2hQXSKJhVlWAJTKdgIpUwCp zutw==
X-Gm-Message-State: AOAM533UMSTPRvKwaiO1ra/A4TLF1SZRJTNKUm1pQGQPSI9gQHgLVSGz 6riX+t25N3s5DONGLehogzbuTb69rhLIxFwKnpM+yw==
X-Google-Smtp-Source: ABdhPJx508j8sVw+V4DuHNbjekwWuCwAteQec0sSYdV9TT564mVo835SNqI8CjPpUsXAdMGXDhM9bMNQ4qhN1FisUkc=
X-Received: by 2002:a92:d347:: with SMTP id a7mr2123508ilh.263.1599835614960; Fri, 11 Sep 2020 07:46:54 -0700 (PDT)
MIME-Version: 1.0
References: <6e071da2-4281-d525-03ba-4d6dfc843a76@innovationslab.net> <CAHbrMsB7T+5Y=2n4LfcXwyAZQSnK4x72R44_2mCDsLhh_zD9Vw@mail.gmail.com> <8C6ABDA8-9A0E-44BB-AE23-43F97AF29730@noware.co.uk> <CAHbrMsD2y0o+uV9eiAb32_=6ZYwAUoS_zM5+T97SxnHzxB05bQ@mail.gmail.com> <0799B139-E353-4EC7-9340-87CE00C465AA@noware.co.uk> <CAHbrMsC=kOYUL_Ei1uSnWJ3hGxu=7c10eRofXJ=w5sQzcbu6mA@mail.gmail.com> <3A9BCDDD-883D-470E-A547-79839149F8EE@sky.uk> <CAHbrMsDVZMNNhwqTUexRL3R=HoEfDTWsoXnr=bdTaWyTXV_=rw@mail.gmail.com> <C8137D01-5903-4CFA-A315-67D7012EC583@noware.co.uk> <CAHbrMsAbGci08qR+NL9Csdej_VFpfZxSdHXfwAM6azB-DryQQQ@mail.gmail.com> <MWHPR16MB153572F70A9CACA49FE01D76EA240@MWHPR16MB1535.namprd16.prod.outlook.com>
In-Reply-To: <MWHPR16MB153572F70A9CACA49FE01D76EA240@MWHPR16MB1535.namprd16.prod.outlook.com>
From: Ben Schwartz <bemasc@google.com>
Date: Fri, 11 Sep 2020 10:46:43 -0400
Message-ID: <CAHbrMsDikJmDNzwmJvvPiZOpvTPkAGwj-Sj3TSzLRgAkr9rbYg@mail.gmail.com>
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@mcafee.com>
Cc: Neil Cook <neil.cook@noware.co.uk>, "Winfield, Alister" <Alister.Winfield@sky.uk>, DNS Privacy Working Group <dns-privacy@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000008e496105af0ac1fd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/5vV43SRuu_5sVZyz4Zb1N7kPV18>
Subject: Re: [dns-privacy] [EXTERNAL] Re: Review request: draft-btw-dprive-rfc8484-clarification
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Sep 2020 14:46:58 -0000

On Fri, Sep 11, 2020 at 1:40 AM Konda, Tirumaleswar Reddy <
TirumaleswarReddy_Konda@mcafee.com> wrote:
...

> * How does the server know which CPE to redirect the client to?
>
>
>
> I’m are assuming here that this is an ISP running both elements so knowing
> how to map the incoming IP to the name its currently using / was told to
> use is relatively trivial.
>
>
>
> Trivial, perhaps, but not necessarily secure.  An adversary in the network
> could alter the IP headers to change the apparent client location, causing
> the client to be redirected to an attacker-controlled CPE, thus defeating
> the integrity assurances of DoH.
>
>
>
> Possible, but I’m not sure this is a practical attack. The attacker would
> need to be able to also change all the IP headers in the return packets to
> their original values (that’s hard enough to do for legit purposes).
>
>
>
>
>
> Sure, but if you assume we don't have a sophisticated active adversary in
> the network, then we don't need authenticated encryption, and we can solve
> this without involving the client at all.
>
>
>
> [TR] The DNS server hosted on the CPE will only be reachable by endpoints
> connected to the home network and not accessible to the outside world. If
> an attacker changes the rules to accept external connections to the DNS
> server hosted on the CPE managed by the ISP, it can take remediation
> measures like block internet access to the compromised router or revoke DNS
> server certificate or block unsolicited incoming traffic to the DNS server
> on the compromised CPE.
>
>
>
> An on-path attacker can change the IP headers but will not succeed
> establishing encrypted DNS session to the DNS server on the
> attacker-controlled CPE.
>

An on-path attacker could be inside the victim's home network, rerouting
the victim's connections into the attacker's network.

My broader point is that the proposed architecture requires a weaker threat
model than the one used by HTTPS (and therefore DoH).  We should consider
that threat model carefully before selecting a solution.  A weaker threat
model can be a good thing: it may mean that there is a much easier solution.


>
> -Tiru
>
>
>
> Also, the attacker has to have compromised an ISP-managed CPE, and that
> CPE still needs to be running on an ISP-managed network connection.
>
>
>
> Maybe.  As Alister noted, in some models the subscriber can acquire a DV
> cert for the name without reaching inside the CPE.
>
>
>
>
>
> Neil
>
>