Re: [secdir] Secdir early review of draft-ietf-opsawg-mud-iot-dns-considerations-03
Ben Schwartz <bemasc@google.com> Mon, 07 March 2022 16:48 UTC
Return-Path: <bemasc@google.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C3D3A0D1D for <secdir@ietfa.amsl.com>; Mon, 7 Mar 2022 08:48:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.609
X-Spam-Level:
X-Spam-Status: No, score=-17.609 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, T_SCC_BODY_TEXT_LINE=-0.01, 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 H6_SUrEg9A3g for <secdir@ietfa.amsl.com>; Mon, 7 Mar 2022 08:48:45 -0800 (PST)
Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 2E1213A101A for <secdir@ietf.org>; Mon, 7 Mar 2022 08:47:24 -0800 (PST)
Received: by mail-il1-x12c.google.com with SMTP id k7so11972214ilo.8 for <secdir@ietf.org>; Mon, 07 Mar 2022 08:47:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vxYrvyF6IA5MO98ejwXL3eK9E0cYiwN24B3wRkJt17M=; b=Qz3RSemArHn3YrbrpGLNXn9owuxHMctmbmfV32CR8BW40difj2phb0TZYF6lcioZTW yckqcPO31HcfTTuAg0FENfgEunxLcWUamKc93vRV1Mlm+Ff1hm9TLXoIvKvyC1uHKrg9 byq+chr8PE/Xm/iOYFpm5ZQtzpeW+gvdZa8NeaXn2S15IBUDHcWzTjuWwehGm5+dSjNz GAAo/XY9FymSsn0esw6/sZSef6oIol/iXtTeG2PcUbxtdceGJijtnw7fbIkmZmvOviCz UgVDNHQ0YDJFevzcqdMmM6AvhsSQKthf8FCa8W3cM6S0y3Sa/sdUDqHDNtGh8Cr9GVIM qn7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vxYrvyF6IA5MO98ejwXL3eK9E0cYiwN24B3wRkJt17M=; b=3O1Yf4Vy/DAPqP5pgD8WTLHa3NT21G8AIEWFhOWPO0WLnTgzFwIRQYKJfiOfDxhmJa mh4FWv9clBNJJN1VDlP3f98HEbU/3fU9XtEX33fmIUrCEsjCmGSVUfazjzeIfArs8ZjS CBuAzeucRDlP+uvY9U6JAogkvgZghn/UhKTlKR+zLPNmOlArMyXtDNFdVDPDnKiw0LhT Xhn4NIrBwtqxLGukRG2Jk5e+8HP+4129m9Ic0ZE4/HJl0mwvFhWZraelHBp/F71dbBkR hKgNgzQjTPuIaW9VnDvg+v5D8tHsCvY9fyQ5AvHPT+BxPIv4FrvGOdmKfj1aPHCRDSny s1MQ==
X-Gm-Message-State: AOAM531pBVoAP9j7hRYnqnK4PhpJ7qJLzheOtV4DS+0KRnFlQIGbZnZW f889GU4jm4gCU4BoDpa/yIpspfcMbS9dGq9PvMAvag==
X-Google-Smtp-Source: ABdhPJy4Mvy4ZOuJ9z6ueSRFg5tznnq8iKhF1nfjNMzSmG0pgwQdZwBhEH7+W3F5MlxphTKaMsOLAZ2ON222Rk7zKJM=
X-Received: by 2002:a92:cd0c:0:b0:2c6:44e8:c630 with SMTP id z12-20020a92cd0c000000b002c644e8c630mr4858094iln.295.1646671643080; Mon, 07 Mar 2022 08:47:23 -0800 (PST)
MIME-Version: 1.0
References: <164661249505.9085.15140248784912063860@ietfa.amsl.com> <1C625713-898F-48D2-97E6-83B23893D3FA@heapingbits.net>
In-Reply-To: <1C625713-898F-48D2-97E6-83B23893D3FA@heapingbits.net>
From: Ben Schwartz <bemasc@google.com>
Date: Mon, 07 Mar 2022 11:47:12 -0500
Message-ID: <CAHbrMsATaT9SBveN94YP=Sr3Z5L9uE8cH=hMm022QkYjnHuDhw@mail.gmail.com>
To: Christopher Wood <caw@heapingbits.net>
Cc: draft-ietf-opsawg-mud-iot-dns-considerations.all@ietf.org, opsawg <opsawg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000005ff67205d9a39e8e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/tb00Oh8wwlJ7X6ssj4HBgNha-Ok>
Subject: Re: [secdir] Secdir early review of draft-ietf-opsawg-mud-iot-dns-considerations-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Mar 2022 16:48:51 -0000
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). [1] https://mailarchive.ietf.org/arch/msg/dnsop/PNJy-kf-6CErJrKf5NSwvTv0srk/ On Sun, Mar 6, 2022 at 7:26 PM Christopher Wood <caw@heapingbits.net> wrote: > Oops. I manually entered the review result in the datatracker form. The > intended review result is “Not Ready." > > > On Mar 6, 2022, at 4:21 PM, Christopher Wood via Datatracker < > noreply@ietf.org> wrote: > > > > Reviewer: Christopher Wood > > Review result: Not Ready > > > > Reviewer: Christopher Wood > > Review result: Has issues > > > > General comments: > > > > In general, the problem statement and motivation for this draft -- and > the > > techniques in Section 3 in particular -- seems underspecified. For > example, > > what are the requirements for the firewall or MUD controller > name<>address > > mappings? Is this mapping ever allowed to be stale? If so, how stale can > it be? > > What is the threat model for the controller when trying to enforce a > name-based > > policy and update its mappings? Does it consider an attacker that tries > to > > interfere with how the mappings are constructed, either via direct > queries to > > DNS or via reverse DNS queries through in-addr.arpa? What privacy > > considerations are relevant in the presence of this (or other) > attackers? What > > sort of assumptions are made about the content or service that is > accessed > > after these DNS queries complete? > > > > Specific comments: > > > > Section 1. > > > > Use of a DNS name rather than IP address in the ACL has many > > advantages: not only does the layer of indirection permit the mapping > > of name to IP address to be changed over time, it also generalizes > > automatically to IPv4 and IPv6 addresses, as well as permitting > > loading balancing of traffic by many different common ways, including > > geography. > > > > I might generalize this a bit to also include multi-CDN deployments for > > services, wherein load balancing might account for geography, load, etc. > > > > Section 3. > > > > In order to compensate for this, the MUD controller SHOULD regularly > > do DNS lookups. These lookups need to be rate limited in order to > > avoid load. It may be necessary to avoid recursive DNS servers in > > order to avoid receiving cached data. > > > > This seems to suggest that controllers should, in the name of "security", > > intentionally bypass resolver caches to ensure their view of the > name<>address > > mappings is never stale. This doesn't seem like great advice, > considering (1) > > the data should always be assumed to be stale (this is a distributed > system, > > after all) and (2) any benign firewall operator may simply try to > increase the > > rate of queries to drive down the probability of working with stale > data. That > > may in turn either overload the authoritative server, or cause the MUD > > controller to be rate limited, yielding the opposite of the desired > effect. > > > > Section 4.2 > > > > Those names are often within some third-party Content-Distribution- > > Network (CDN) system, or may be arbitrary names in a cloud-provider > > storage system such as Amazon S3 (such [AmazonS3], or [Akamai]). > > > > Does this mean to say that the names are unpredictably chosen by the > content > > provider, and not by the content owner? If so, I might rephrase it as > such. > > > > Section 4.3 > > > > Some CDNs make all customer content at a single URL (such as > > s3.amazonaws.com). This seems to be ideal from a MUD point of view: > > a completely predictable URL. The problem is that a compromised > > device could then connect to any S3 bucket, potentially attacking > > other buckets. > > > > What does "attacking other buckets" mean here? Does it mean increasing > number > > of reads to those buckets? Or perhaps _writing_ to those buckets? I > don't know > > what sort of access control techniques are typically used here, but the > latter, > > i.e., people writing to arbitrary buckets, would be surprising to me. In > any > > case, I would clarify what is meant here, along with what assumptions > are made > > about the content providers themselves. > > > > Section 5. > > > > There are significant privacy issues with having IoT devices sending > > their DNS queries to an outside entity. Doing it over a secure > > transport (DoT/DoH) is clearly better than doing so on port 53. The > > providers of the secure resolver service will, however, still see the > > IoT device queries. > > > > This seems to be assuming a particular threat model that may not be > universally > > applicable. It may not be the case that using a public resolver will > lead to > > "significant privacy issues." I might clarify the assumed threat model > here, > > rather than prescribe one for all users of this document. > > > > Moreover, if something like Oblivious DoH were used, would this still be > an > > issue? ODoH is mentioned later on in the privacy considerations, but I > think it > > warrants mention here as well. > > > > Section 6.5. > > > > Use of public QuadX resolver instead of the provided DNS resolver, > > whether Do53, DoT or DoH is discouraged. Should the network provide > > such a resolver for use, then there is no reason not to use it, as > > the network operator has clearly thought about this. > > > > I would push back on this. As I understand the situation, some ISP > recursive > > resolvers essentially forward queries onwards to public (QuadX) > resolvers. > > What's the difference, then, between using the public resolver directly > and the > > network-provided resolver? (This points back to the previous comment on > the > > assumed threat model.) > > > > Section 6.5. > > > > The recommendation here is to do this only when the provided > > resolvers provide no answers to any queries at all, and do so > > repeatedly. The use of the operator provided resolvers SHOULD be > > retried on a periodic basis, and once they answer, there should be no > > further attempts to contact public resolvers. > > > > I think this needs a better description of the threat model in order to > make > > sense. What if, for example, some attacker basically blocked all answers > from > > provided resolvers, forcing usage of public resolvers? Is that in scope > or not? > > > > > > _______________________________________________ > > secdir mailing list > > secdir@ietf.org > > https://www.ietf.org/mailman/listinfo/secdir > > wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview >
- [secdir] Secdir early review of draft-ietf-opsawg… Christopher Wood via Datatracker
- Re: [secdir] Secdir early review of draft-ietf-op… Christopher Wood
- Re: [secdir] Secdir early review of draft-ietf-op… Ben Schwartz
- Re: [secdir] [OPSAWG] Secdir early review of draf… Michael Richardson
- Re: [secdir] [OPSAWG] Secdir early review of draf… Ben Schwartz