Re: [OPSAWG] [secdir] Secdir early review of draft-ietf-opsawg-mud-iot-dns-considerations-03
Eliot Lear <lear@lear.ch> Mon, 28 March 2022 19:27 UTC
Return-Path: <lear@lear.ch>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079173A17C6; Mon, 28 Mar 2022 12:27:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.9
X-Spam-Level:
X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
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 heR1ItE30Mq2; Mon, 28 Mar 2022 12:27:49 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 969563A11D9; Mon, 28 Mar 2022 12:27:48 -0700 (PDT)
Received: from [IPV6:2001:420:c0c0:1011::6] ([IPv6:2001:420:c0c0:1011:0:0:0:6]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 22SJRjM2301168 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 28 Mar 2022 21:27:45 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1648495666; bh=bICCnVnKQb/b6knJmuB0ttFaNUMvZ9E9QW4sibmU6Fw=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=L8f/5mDRbXUkfBerq/kcG+2r21cOgOk+ssz461/rZNBYRzKfQgECF6NF3yxe9jq0i YOPKMmuvSshcxVCnyrlVG18K+8JoieGU6+scfwlBiF701Bg02QQnJcqedQxQzjgHwP U/iYh0GNqR4IZKgo/lqGb9DZ68MZWvOYw0hLnmQw=
Content-Type: multipart/alternative; boundary="------------7VEhxvC2CVNxrQj70uT64Dqd"
Message-ID: <9eb3b69a-f9fd-6c01-e25e-6b7d8351dd43@lear.ch>
Date: Mon, 28 Mar 2022 21:27:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
Content-Language: en-US
From: Eliot Lear <lear@lear.ch>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>
Cc: opsawg <opsawg@ietf.org>, mud@ietf.org
References: <164661249505.9085.15140248784912063860@ietfa.amsl.com> <1C625713-898F-48D2-97E6-83B23893D3FA@heapingbits.net> <CAHbrMsATaT9SBveN94YP=Sr3Z5L9uE8cH=hMm022QkYjnHuDhw@mail.gmail.com> <81b54118-a080-b09f-3591-d303b8b6e2ec@sandelman.ca> <CAHbrMsDZizpDAVXX-BhKo15p7N0kAa3mhwujO=emU2aWmRsupQ@mail.gmail.com> <99655964-13c8-69a0-2965-ca9c67447e03@rfc-editor.org>
In-Reply-To: <99655964-13c8-69a0-2965-ca9c67447e03@rfc-editor.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/HkJvh_ZxkggJ-7g6KLNCwpzXTd8>
Subject: Re: [OPSAWG] [secdir] Secdir early review of draft-ietf-opsawg-mud-iot-dns-considerations-03
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Mar 2022 19:27:54 -0000
My apologies. This should have gone out under my name, not under that of the ISE. The ISE has no interest in this. Eliot On 28.03.22 21:25, Independent Submissions Editor (Eliot Lear) wrote: > > I think there are two things going on here. > > First, there is a need for the controller to be tightly bound with the > resolver. Thus it is aware of what is returned to the device. How > long the device uses that information should be governed by the upper > bound of DNS caching semantics and stateful access mechanisms. > > The second thing going on here is that the device needs to do a new > lookup if the TTL on a record has expired, and it has unexpectedly > lost connectivity, something that can happen on the Internet with or > without MUD. In fact, MUD is hardly the issue here. The issue is > whether you can have DNS-based ACLs that can function. Here the > enforcement point has something to say to make that happen, because > resilience requirements on the client will dictate it happening. > > Eliot > > On 28.03.22 21:00, Ben Schwartz wrote: >> >> >> On Sat, Mar 26, 2022 at 8:32 PM Michael Richardson >> <mcr+ietf@sandelman.ca <mailto:mcr%2Bietf@sandelman.ca>> wrote: >> >> On 2022-03-07 11:47, Ben Schwartz wrote: >> > I reviewed [1] this draft at version 01, but my concerns >> largely stand with >> > the current version. >> > >> > The fundamental issue here, in my view, is that the >> urn:ietf:params:mud:dns >> > permission is not compatible with the desired threat model. A >> correct >> > solution would be to recommend against this permission, and >> introduce a new >> > one that provides explicit coupling between DNS resolution, >> transport >> > setup, and the MUD gateway (e.g. using a SOCKS5 proxy). >> >> I have been struggling to find a way to deal with your comments. >> https://github.com/mcr/iot-mud-dns-considerations/pull/2 is the >> beginnings of a recommendation to use SOCKS5 if it is present on >> networks. I don't think that we have a way to do that. >> >> Perhaps there is some discovery of SOCKS5 in some vendor DHCP >> option, >> but I haven't found that yet. >> >> >> Local SOCKS5 proxies are conventionally discovered via WPAD [1], >> which returns a PAC file [2]. I'm no great fan of WPAD, but it is >> widely implemented in browsers and OSes. >> >> I don't mean to claim that SOCKS5 specifically, or domain-oriented >> transport proxies generally, are the right solution here. My point >> is that the MUD gateway architecture described here is fatally >> flawed. Specifically, I'm focused on this text: >> >> Aside from the list of records being incomplete, the list may have >> changed between the time that the MUD controller did the lookup and >> the time that the IoT device does the lookup, and this change can >> result in a failure for the ACL to match. >> >> In order to compensate for this, the MUD controller SHOULD regularly >> do DNS lookups in order to get never have stale data. These lookups >> need to be rate limited in order to avoid load. It may be necessary >> to avoid local recursive DNS servers. The MUD controller SHOULD >> incorporate its own recursive caching DNS server. Properly designed >> recursive servers should cache data for many minutes to days, while >> the underlying DNS data can change at a higher frequency, providing >> different answers to different queries! >> >> A MUD controller that is aware of which recursive DNS server that the >> IoT device will use can instead query that server on a periodic >> basis. >> >> The problem description here is accurate, but the proposed MUD >> controller behaviors are not reliably compatible with RFC >> 8520-compliant devices, so they cannot safely be deployed. The only >> reliable solution is to update the allowed IPs based on the specific >> DNS responses that are being used by the device's connections. This >> could either be done implicitly (via a transport proxy) or explicitly >> (by ensuring the MUD controller _is_ the client's DNS resolver, and >> adding IP ACLs before returning any DNS response containing IP >> addresses). >> >> This also touches on another issue with MUD DNS support: RFC 8520 >> does not clearly define any rule regarding the allowed DNS QNAMEs. >> This enables arbitrary data flows to be tunneled through the DNS to >> arbitrary destinations. In my view, this is a very large hole in the >> MUD protections. A transport proxy or tighter DNS binding would also >> help to close this loophole. >> >> [1] https://datatracker.ietf.org/doc/html/draft-ietf-wrec-wpad-01 >> [2] >> https://developer.mozilla.org/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling/Proxy_Auto-Configuration_PAC_file >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg
- [OPSAWG] Secdir early review of draft-ietf-opsawg… Christopher Wood via Datatracker
- Re: [OPSAWG] [secdir] Secdir early review of draf… Christopher Wood
- Re: [OPSAWG] [secdir] Secdir early review of draf… Ben Schwartz
- Re: [OPSAWG] [secdir] Secdir early review of draf… Michael Richardson
- Re: [OPSAWG] [secdir] Secdir early review of draf… Ben Schwartz
- Re: [OPSAWG] [secdir] Secdir early review of draf… Michael Richardson
- Re: [OPSAWG] [secdir] Secdir early review of draf… Ben Schwartz
- Re: [OPSAWG] [secdir] Secdir early review of draf… Independent Submissions Editor (Eliot Lear)
- Re: [OPSAWG] [secdir] Secdir early review of draf… Eliot Lear
- Re: [OPSAWG] [secdir] Secdir early review of draf… Michael Richardson