Re: [Add] Authentication Sub-topics for Tuesday Interim (homework for Tuesday's meeting)

Tommy Pauly <tpauly@apple.com> Tue, 15 September 2020 12:45 UTC

Return-Path: <tpauly@apple.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A86673A09A8 for <add@ietfa.amsl.com>; Tue, 15 Sep 2020 05:45:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.815
X-Spam-Level:
X-Spam-Status: No, score=-3.815 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 EhevX2wU2Hpw for <add@ietfa.amsl.com>; Tue, 15 Sep 2020 05:45:30 -0700 (PDT)
Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72ADE3A0F4C for <add@ietf.org>; Tue, 15 Sep 2020 05:45:15 -0700 (PDT)
Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.43/8.16.0.42) with SMTP id 08FCVeb2064645; Tue, 15 Sep 2020 05:45:11 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : content-transfer-encoding : from : mime-version : subject : date : message-id : references : cc : in-reply-to : to; s=20180706; bh=KwYLdxVnjG0Ez2Qh4/xEVcdVG0e8/zC5ZCtjthfiM74=; b=BSp6SldGtglWIrX/aDb6NLi69Y8BVscQErdy//CIaxdAJvA6smT5gZctxzTMkYZ8EYk2 9Kl845AmczUyNF+9RCyme4ygxLydQzZycdP4w7+FJd79crBNzxoZD0dQgQA1zrdeTIy2 hj+SFAFkbqqKycTgIF+zIJfYv6MxCHUx7LNQypA4sXGdUJ2AXIo4XwoBTpJMfbEmRA4n L+2ASvDAw36MQ+Q28CWrOfWKNAO9dgKu8ttLclbrXFc/Q75bppk8OMdTcOwXUISVQT8L HxFqMfQzplUS2ydN8r0kz98OaLga2LXZ48Ced0WHpvBRzGtXPEVg1gzvDJReH0awvodb AA==
Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by nwk-aaemail-lapp02.apple.com with ESMTP id 33gtwff4au-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 15 Sep 2020 05:45:11 -0700
Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QGP00NI0A3AZ090@rn-mailsvcp-mta-lapp04.rno.apple.com>; Tue, 15 Sep 2020 05:45:10 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QGP00P009PPR800@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Tue, 15 Sep 2020 05:45:10 -0700 (PDT)
X-Va-A:
X-Va-T-CD: f59ad7add785c48d6148478adda1a472
X-Va-E-CD: 1c7b55b78e3578219f1e6d8c46f0bd16
X-Va-R-CD: 2e27eead26b8d798892b0ed9967363bf
X-Va-CD: 0
X-Va-ID: edbb13e3-8dd9-49b7-a071-6a456e26005a
X-V-A:
X-V-T-CD: f59ad7add785c48d6148478adda1a472
X-V-E-CD: 1c7b55b78e3578219f1e6d8c46f0bd16
X-V-R-CD: 2e27eead26b8d798892b0ed9967363bf
X-V-CD: 0
X-V-ID: 32a94743-96cd-46d3-b816-586ba2f6bf1d
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-15_08:2020-09-15, 2020-09-15 signatures=0
Received: from localhost.localdomain (unknown [10.104.127.189]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QGP00Y5KA39DC00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Tue, 15 Sep 2020 05:45:10 -0700 (PDT)
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: quoted-printable
From: Tommy Pauly <tpauly@apple.com>
MIME-version: 1.0 (1.0)
Date: Tue, 15 Sep 2020 05:45:08 -0700
Message-id: <AC23D073-E47C-43DF-BDCB-F68252DE996A@apple.com>
References: <8C4D5527-C89C-4A8F-B8FE-CDF509783A0C@fl1ger.de>
Cc: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, Eric Rescorla <ekr@rtfm.com>, ADD Mailing list <add@ietf.org>, "Deen, Glenn" <Glenn_Deen@comcast.com>
In-reply-to: <8C4D5527-C89C-4A8F-B8FE-CDF509783A0C@fl1ger.de>
To: Ralf Weber <dns@fl1ger.de>
X-Mailer: iPhone Mail (18A373)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-15_08:2020-09-15, 2020-09-15 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/qxrEGJKbymiS_sZ1CBqVYsm05VY>
Subject: Re: [Add] Authentication Sub-topics for Tuesday Interim (homework for Tuesday's meeting)
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Sep 2020 12:45:32 -0000


> On Sep 15, 2020, at 3:01 AM, Ralf Weber <dns@fl1ger.de> wrote:
> 
> Moin!
> 
> On 15 Sep 2020, at 4:48, Tommy Pauly wrote:
> […]
>> What might not be possible, on the other hand, is to usefully authenticate a deployment model where the resolver or forwarder is some private/local address that’s running on a router itself–unless this is a managed network or managed device that has some out of band mechanism to trust or configure resolvers (at which point we don’t need discovery mechanisms). I think the case of trying to find an equivalent and trusted resolver to the one running on 10.0.0.1 on my router ends up being indistinguishable from an attack scenario. But these scenarios likely aren’t worth solving this way anyhow—if the DoH server isn’t on my router itself, but hosted in the ISP network, the network would do better to provision the address of that ISP server instead of a local address; and if I really have a DoH server running locally, the router would presumably be able to upgrade to be able to provision the DoH information directly in DHCP/RA/PvD.
> I think upgrading via the CPE is worth doing, as even a caching forwarder has benefits. The solutions you provide (DHCP/RA/Pvd) don’t provide authentication. Does that mean you are ok to accept unauthenticated DoH URIs from these solutions, but not from an CPE/DNS based auto upgrade?

That’s a good question to raise. One difference is that spoofing the provisioning protocol means the attacker has to be a bit more involved in order to pull off an attack without detection—you can become a man-in-the-middle and act as the effective router, which is a different level of attack than injecting a DNS response to convince a device to use some arbitrary DoH server of the attacker’s choosing. (There are also some anti-spoofing features like RA-guard which could make it harder to attack than injecting DNS responses.)

This is largely based on the choice of attacker model I described at the top of my email—to consider attackers who aren’t a man-in-the-middle for DHCP, which means your Do53 is already a problem. A different choice of attacks to prevent can lead to a different set of acceptable solutions. However, I’m not sure which models would support unauthenticated upgrade for a CPE based resolver. 

Best,
Tommy

> 
> So long
> -Ralf
> ——-
> Ralf Weber
> 
> -- 
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add