From nobody Sat Mar 26 17:32:32 2022 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5235A3A1227; Sat, 26 Mar 2022 17:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca 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 xt4SVBRZh3-R; Sat, 26 Mar 2022 17:32:24 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22CCC3A0C80; Sat, 26 Mar 2022 17:32:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 345E538B1A; Sat, 26 Mar 2022 20:42:52 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vsjG8zHA9xPu; Sat, 26 Mar 2022 20:42:48 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E812138A5F; Sat, 26 Mar 2022 20:42:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1648341767; bh=GlULwd3yRomeNDZ5maPALQSNWb2jqaWAsA+9B6sxeRA=; h=Date:Subject:To:References:Cc:From:In-Reply-To:From; b=foGM77YrHpr2q3J0sfCwQFSiHz3RN2gCOjx68FNpA5u2M0fz4uAdQmFcItjM38A4v 9Ef4gprpNIJAvR3HF9BfSAaiZxMlyA4INIVyWC1kxKqIYEVv9255DMLxJzIngEF5AK hlpgfkCskShiH+R3BtuVMyY1Rv8CYP7lmPaPqNY1CN7f6Vi+W1aG99GNgnNBDcUq9N AIKx2nWiG/nLEm4CnM6dPQ9vDHTXdrMEhnkbwBHemwKqAVc+gAAjALlfSUn7tJboVa TeDLFSQAjIeWSzk0IQIztdTSSOsvxDUktkMl7YNp0qCyUVbwfCjhKYPLhJOYLtzCUV Js47bOtFuZvjg== Received: from [127.0.0.1] (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id DB323444; Sat, 26 Mar 2022 20:32:15 -0400 (EDT) Message-ID: <81b54118-a080-b09f-3591-d303b8b6e2ec@sandelman.ca> Date: Sat, 26 Mar 2022 20:32:15 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Content-Language: en-US To: opsawg@ietf.org, mud@ietf.org References: <164661249505.9085.15140248784912063860@ietfa.amsl.com> <1C625713-898F-48D2-97E6-83B23893D3FA@heapingbits.net> Cc: bemasc@google.com From: Michael Richardson In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Mud] [OPSAWG] [secdir] Secdir early review of draft-ietf-opsawg-mud-iot-dns-considerations-03 X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2022 00:32:30 -0000 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. From nobody Mon Mar 28 12:01:37 2022 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D863A19C9 for ; Mon, 28 Mar 2022 12:01:26 -0700 (PDT) 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 uA7k4Azw17vW for ; Mon, 28 Mar 2022 12:01:22 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 025133A18C5 for ; Mon, 28 Mar 2022 12:01:11 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id e22so18260969ioe.11 for ; Mon, 28 Mar 2022 12:01:11 -0700 (PDT) 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=01cuA2oGkZmudf8Fja5PZKplT732qfBYSSLAgJ9hJSA=; b=ew8V6HIuMkV079ELZQNBdmDMU/0uaA29JHYWPwhd+J8Hc2n3Wf+xw8qOnf0Xh69BKg Bm3/dPD9vLBjCL8s2QbfiRNcWDgAwb3CG68ZSat/2Ysf1Z2aLYxDBZ7wRxErpiofYehn QL0CNzQKI62Xbw4JUi+9LfByoMG3K+EG5f6GhDV2Tt2LzifR5M7j6Nk3wUIex3Ia2zvG oQF1tWFSLKLQ4Q++VKcq48t646x9zJbgbTfK1NvKHUnSgIY6hKb5HxBE4/Uw8eJk4kHl OMQX9AVX7D8W5Sl8iZC2oLVKbpCd4aB6/R91xegI5XJJJHy9uW6x0PD7vB4Pdq03TIcP Bo2g== 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=01cuA2oGkZmudf8Fja5PZKplT732qfBYSSLAgJ9hJSA=; b=NouCtzLNePjmYuX7bfqLYH8vgktEe+7G8p9f2X/7GVRMhIkTWRrZ43yx+NLPi9ctZm Wl8/Fei/bmBdFImpZdHCv4VbQ8sZHUz1RgAND6ItviijSgy2ukfOBlx/j69oYtddBMXG LLSPygszXaiSpx4218dmaprEWszu8YBjN/7cQeI2YSXQ7MIc0sKhYl8u/bB8R6NYfS9y Um+aAwPRPU3rbujvdeJyZGMNO70pOA7rveMeg9Y86G1zreKgJtWXBvgG3q9kfcGSgixZ T8++mTqpQXyK6iI3ltclBefVgTRH7ca5/AnbjSs6rJlyJQW75hkLaLG9ME2zYGfBPbXT nXPA== X-Gm-Message-State: AOAM5302eyNREtO9n0/vxciBhAMxUUI+fSlOFFCqsLr9/seiQrd4G8i+ VF9HLB9p2oSMPMk/ttXOf0dm1wiEyf1U5QJJ8SjmwA== X-Google-Smtp-Source: ABdhPJwxMDz0hGymkfjySFWeNhb8KfT0n6hK1sbI7ie28Yig5VNAeGCgHU1uTvmfnXcZDjLLBMGSZPSA10GhiJTfXxs= X-Received: by 2002:a02:cb98:0:b0:323:64bb:7c57 with SMTP id u24-20020a02cb98000000b0032364bb7c57mr4592886jap.126.1648494070579; Mon, 28 Mar 2022 12:01:10 -0700 (PDT) MIME-Version: 1.0 References: <164661249505.9085.15140248784912063860@ietfa.amsl.com> <1C625713-898F-48D2-97E6-83B23893D3FA@heapingbits.net> <81b54118-a080-b09f-3591-d303b8b6e2ec@sandelman.ca> In-Reply-To: <81b54118-a080-b09f-3591-d303b8b6e2ec@sandelman.ca> From: Ben Schwartz Date: Mon, 28 Mar 2022 19:00:59 +0000 Message-ID: To: Michael Richardson Cc: opsawg , mud@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000084855b05db4befac" Archived-At: Subject: Re: [Mud] [OPSAWG] [secdir] Secdir early review of draft-ietf-opsawg-mud-iot-dns-considerations-03 X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2022 19:01:35 -0000 --00000000000084855b05db4befac Content-Type: multipart/alternative; boundary="0000000000007e190405db4bef7d" --0000000000007e190405db4bef7d Content-Type: text/plain; charset="UTF-8" On Sat, Mar 26, 2022 at 8:32 PM Michael Richardson 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 --0000000000007e190405db4bef7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Mar 26, 2022 at 8:32 PM Micha= el Richardson <mcr+ietf@sande= lman.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:mu= d:dns
> permission is not compatible with the desired threat model.=C2=A0 A co= rrect
> solution would be to recommend against this permission, and introduce = a new
> one that provides explicit coupling between DNS resolution, transport<= br> > 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-considera= tions/pull/2 is the
beginnings of a recommendation to use SOCKS5 if it is present on
networks.=C2=A0 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].=C2=A0 I'm no great fan of WPAD, but it is widely impleme= nted in=C2=A0browsers and OSes.

I don't mean t= o claim that SOCKS5 specifically, or domain-oriented transport proxies gene= rally, are the right solution here.=C2=A0 My point is that the MUD gateway = architecture described here is fatally flawed.=C2=A0 Specifically, I'm = focused on this text:

=C2=A0 =C2=A0Aside from the = list of records being incomplete, the list may have
=C2=A0 =C2=A0changed= between the time that the MUD controller did the lookup and
=C2=A0 =C2= =A0the time that the IoT device does the lookup, and this change can
=C2= =A0 =C2=A0result in a failure for the ACL to match.

=C2=A0 =C2=A0In = order to compensate for this, the MUD controller SHOULD regularly
=C2=A0= =C2=A0do DNS lookups in order to get never have stale data.=C2=A0 These lo= okups
=C2=A0 =C2=A0need to be rate limited in order to avoid load.=C2=A0= It may be necessary
=C2=A0 =C2=A0to avoid local recursive DNS servers.= =C2=A0 The MUD controller SHOULD
=C2=A0 =C2=A0incorporate its own recurs= ive caching DNS server.=C2=A0 Properly designed
=C2=A0 =C2=A0recursive s= ervers should cache data for many minutes to days, while
=C2=A0 =C2=A0th= e underlying DNS data can change at a higher frequency, providing
=C2=A0= =C2=A0different answers to different queries!

=C2=A0 =C2=A0A MUD co= ntroller that is aware of which recursive DNS server that the
=C2=A0 =C2= =A0IoT device will use can instead query that server on a periodic
=C2= =A0 =C2=A0basis.

The problem description here = is accurate, but the proposed MUD controller behaviors are not reliably com= patible with RFC 8520-compliant devices, so they cannot safely be deployed.= =C2=A0 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= .=C2=A0 This could either be done implicitly (via a transport proxy) or exp= licitly (by ensuring the MUD controller _is_ the client's DNS resolver,= and adding IP ACLs before returning any DNS response containing IP address= es).

This also touches on another issue with MUD D= NS support: RFC 8520 does not clearly define any rule regarding the allowed= DNS QNAMEs.=C2=A0 This enables arbitrary data flows to be tunneled through= the DNS to arbitrary destinations.=C2=A0 In my view, this is a very large = hole in the MUD protections.=C2=A0 A transport proxy or tighter DNS binding= would also help to close this loophole.

=C2=A0
--0000000000007e190405db4bef7d-- --00000000000084855b05db4befac Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPmwYJKoZIhvcNAQcCoIIPjDCCD4gCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggz1MIIEtjCCA56gAwIBAgIQeAMYYHb81ngUVR0WyMTzqzANBgkqhkiG9w0BAQsFADBMMSAwHgYD VQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UE AxMKR2xvYmFsU2lnbjAeFw0yMDA3MjgwMDAwMDBaFw0yOTAzMTgwMDAwMDBaMFQxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFz IFIzIFNNSU1FIENBIDIwMjAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvLe9xPU9W dpiHLAvX7kFnaFZPuJLey7LYaMO8P/xSngB9IN73mVc7YiLov12Fekdtn5kL8PjmDBEvTYmWsuQS 6VBo3vdlqqXZ0M9eMkjcKqijrmDRleudEoPDzTumwQ18VB/3I+vbN039HIaRQ5x+NHGiPHVfk6Rx c6KAbYceyeqqfuJEcq23vhTdium/Bf5hHqYUhuJwnBQ+dAUcFndUKMJrth6lHeoifkbw2bv81zxJ I9cvIy516+oUekqiSFGfzAqByv41OrgLV4fLGCDH3yRh1tj7EtV3l2TngqtrDLUs5R+sWIItPa/4 AJXB1Q3nGNl2tNjVpcSn0uJ7aFPbAgMBAAGjggGKMIIBhjAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHzM CmjXouseLHIb0c1dlW+N+/JjMB8GA1UdIwQYMBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MHsGCCsG AQUFBwEBBG8wbTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29tL3Jvb3Ry MzA7BggrBgEFBQcwAoYvaHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvcm9vdC1y My5jcnQwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIz LmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5n bG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEANyYcO+9JZYyqQt41 TMwvFWAw3vLoLOQIfIn48/yea/ekOcParTb0mbhsvVSZ6sGn+txYAZb33wIb1f4wK4xQ7+RUYBfI TuTPL7olF9hDpojC2F6Eu8nuEf1XD9qNI8zFd4kfjg4rb+AME0L81WaCL/WhP2kDCnRU4jm6TryB CHhZqtxkIvXGPGHjwJJazJBnX5NayIce4fGuUEJ7HkuCthVZ3Rws0UyHSAXesT/0tXATND4mNr1X El6adiSQy619ybVERnRi5aDe1PTwE+qNiotEEaeujz1a/+yYaaTY+k+qJcVxi7tbyQ0hi0UB3myM A/z2HmGEwO8hx7hDjKmKbDCCA18wggJHoAMCAQICCwQAAAAAASFYUwiiMA0GCSqGSIb3DQEBCwUA MEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWdu MRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAwMFoXDTI5MDMxODEwMDAwMFowTDEg MB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzAR BgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJXaQeQZ4 Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG4VKrDIFHcGzdZNHr9SyjD4I9DCuu l9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnLJlkNc96wyOkmDoMVxu9bi9IEYMpJ pij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDhBjPogiuuU6Y6FnOM3UEOIDrAtKeh 6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjRAjFhGV64l++td7dkmnq/X8ET75ti +w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0bvDANBgkqhkiG9w0BAQsFAAOCAQEA S0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAtrqQK0/Xx8Q+Kv3NnSoPHRHt44K9u bG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6DuM81IcPJaP7O2sJTqsyQiunwXUaM ld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCekTBtzc3b0F5nCH3oO4y0IrQocLP88 q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMfOjsl0oZAzjsshnjJYS8Uuu7bVW/f hO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBNQwggO8oAMCAQICEAFk+UNTHyug54ns1NPB 4LIwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gQXRsYXMgUjMgU01JTUUgQ0EgMjAyMDAeFw0yMjAyMTQx MTE4MjdaFw0yMjA4MTMxMTE4MjdaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFzY0Bnb29nbGUuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1/DJraDLTBFEc4/3RWSEOgDoA+7UZNjE bOSBOHrRYpr3cwDMUiepgOUXZX8QFjP3LlNeHCKb62oprDO6f6FNQEv8sEUa/+g/WTDlWN4cN0Ue NMVQUyYpSSQB554zo0u7mjZCsp2SSQqQwqrJI+zjkpPRSxjDkTPzYcRFdqcIzGnpSoj5gztnN+ci odXzWcZV7ZWUmxqhROlXRgS+jLleAMMHRwxAwZ/7fDm/V1sfyb/NW0dA78GCw58dBNgYveslXNpO xHucOQXo0J34zY96fc9CMdk6hju0pHxBFmWYrJXfG4mp6rIrRP/uw3Klnqh+/XD4R7SohOF41S0j mU23mQIDAQABo4IB0jCCAc4wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5jb20wDgYDVR0PAQH/ BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUUmFfZbsTFShh g/GfrQy0l+x6gMEwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYmaHR0cHM6 Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wDAYDVR0TAQH/BAIwADCBmgYIKwYBBQUH AQEEgY0wgYowPgYIKwYBBQUHMAGGMmh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL2NhL2dzYXRs YXNyM3NtaW1lY2EyMDIwMEgGCCsGAQUFBzAChjxodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29t L2NhY2VydC9nc2F0bGFzcjNzbWltZWNhMjAyMC5jcnQwHwYDVR0jBBgwFoAUfMwKaNei6x4schvR zV2Vb4378mMwRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9jYS9n c2F0bGFzcjNzbWltZWNhMjAyMC5jcmwwDQYJKoZIhvcNAQELBQADggEBAAuQ0Du5aufsQXByAC1B NcBo9lgU5gE+PpUOnRUAgnEinQiyzGjbtS8ZMT3uZaOem3T7Lij32jqR+pkgHp92XxWx9xnTcB+D X4bN4yHtKPrvN4cDzvIrcRnwAzqyXIJOKEUvJ/FaCm1VFU3U6InKylUC9Ysh7Dz6s5yR3KLYeTG8 l1k1EdNofFZcc+CfDKsHddeWmxb4pAz/eIkSHpac6YD4jq0SCQWZ93bEuWecJa5+/DeGmFlgifxm dJwXoyPfU8YaOTXQXTrQwJUvTVS7zddmJoPHWkZqcbbramT1I4ReJ0OhmaghIxxifYIifUr1xivI MsMTN0pwxSj5U2MqT/8xggJqMIICZgIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i YWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFzIFIzIFNNSU1FIENBIDIwMjAC EAFk+UNTHyug54ns1NPB4LIwDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIA9PBin9 sA88qdA9G3NZyqhsPO3zyf9A+C21x7iGQiLyMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTIyMDMyODE5MDExMVowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASow CwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZI hvcNAQEHMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQCBQTFUfTItB8dkltZ47HWCINNc O05gPwu+lWEtGGwWa83NNAQvAvcvOdVH6aR5S7ob/Fu8PLO6KsN7qwA2ofAMOTuSMG09+pPlpcug 9/62IlwYLZo7BtBVSUhnT3ZytB05W3cMSGzobAEEvkOHcNtS6SBA2r5mb966CxYWmBPAHoCUGYC1 WLr3yjCwWD3ILy/hRWN68Hry5uyilGZ5xRqAZSAbgoYLUpTBPNSZLzkq7mwCBioUOE2drWh8zYXi 4Z5xMELtDPQBFgthAmbGRkNbsptyliRup0VOHyaiJhF2P/MFI6Ojm4kfdNuAuqxZJYljyByubAah f1l15Px/E7TR --00000000000084855b05db4befac-- From nobody Mon Mar 28 12:26:37 2022 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723AA3A17D4; Mon, 28 Mar 2022 12:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ctVnO3dKBa2Q; Mon, 28 Mar 2022 12:26:02 -0700 (PDT) Received: from [IPV6:2001:420:c0c0:1011::6] (unknown [IPv6:2001:420:c0c0:1011::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 345913A17CF; Mon, 28 Mar 2022 12:26:01 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------L6HLaR1628mmKJqJJi1yaLZl" Message-ID: <99655964-13c8-69a0-2965-ca9c67447e03@rfc-editor.org> Date: Mon, 28 Mar 2022 21:25:58 +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 To: Ben Schwartz , Michael Richardson Cc: opsawg , mud@ietf.org References: <164661249505.9085.15140248784912063860@ietfa.amsl.com> <1C625713-898F-48D2-97E6-83B23893D3FA@heapingbits.net> <81b54118-a080-b09f-3591-d303b8b6e2ec@sandelman.ca> From: "Independent Submissions Editor (Eliot Lear)" In-Reply-To: Archived-At: Subject: Re: [Mud] [OPSAWG] [secdir] Secdir early review of draft-ietf-opsawg-mud-iot-dns-considerations-03 X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2022 19:26:09 -0000 This is a multi-part message in MIME format. --------------L6HLaR1628mmKJqJJi1yaLZl Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 > > 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 --------------L6HLaR1628mmKJqJJi1yaLZl Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

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

 

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
--------------L6HLaR1628mmKJqJJi1yaLZl-- From nobody Mon Mar 28 12:28:14 2022 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@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 To: Ben Schwartz , Michael Richardson Cc: opsawg , mud@ietf.org References: <164661249505.9085.15140248784912063860@ietfa.amsl.com> <1C625713-898F-48D2-97E6-83B23893D3FA@heapingbits.net> <81b54118-a080-b09f-3591-d303b8b6e2ec@sandelman.ca> <99655964-13c8-69a0-2965-ca9c67447e03@rfc-editor.org> In-Reply-To: <99655964-13c8-69a0-2965-ca9c67447e03@rfc-editor.org> Archived-At: Subject: Re: [Mud] [OPSAWG] [secdir] Secdir early review of draft-ietf-opsawg-mud-iot-dns-considerations-03 X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2022 19:27:54 -0000 This is a multi-part message in MIME format. --------------7VEhxvC2CVNxrQj70uT64Dqd Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 >> > 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 --------------7VEhxvC2CVNxrQj70uT64Dqd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

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

 

_______________________________________________
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
--------------7VEhxvC2CVNxrQj70uT64Dqd-- From nobody Mon Mar 28 15:19:28 2022 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5393A19A4; Mon, 28 Mar 2022 15:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 b3lSpealfoef; Mon, 28 Mar 2022 15:18:47 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00:e000:2bb::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C35283A199F; Mon, 28 Mar 2022 15:18:46 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [75.98.19.151]) by relay.sandelman.ca (Postfix) with ESMTPS id 293011F45E; Mon, 28 Mar 2022 22:18:44 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id BBE0A1A0215; Tue, 29 Mar 2022 00:18:41 +0200 (CEST) From: Michael Richardson To: Ben Schwartz , opsawg , mud@ietf.org In-reply-to: References: <164661249505.9085.15140248784912063860@ietfa.amsl.com> <1C625713-898F-48D2-97E6-83B23893D3FA@heapingbits.net> <81b54118-a080-b09f-3591-d303b8b6e2ec@sandelman.ca> Comments: In-reply-to Ben Schwartz message dated "Mon, 28 Mar 2022 19:00:59 -0000." X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Mon, 28 Mar 2022 18:18:41 -0400 Message-ID: <113677.1648505921@dooku> Archived-At: Subject: Re: [Mud] [OPSAWG] [secdir] Secdir early review of draft-ietf-opsawg-mud-iot-dns-considerations-03 X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2022 22:18:52 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Ben Schwartz wrote: > 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. Yeah, that's not going to fly. } [1] https://datatracker.ietf.org/doc/html/draft-ietf-wrec-wpad-01=20 1) draft-ietf-wrec-wpad is a 22 year old ID which specifies use of a private-use DHCP option (252). =20=20=20 While one think one can get away with an SRV entry, that requires local DNS to be working, which is exactly the kind of thing that IoT manufacturers are having trouble relying upon. (Yes, if a MUD controller is present, we can expect local DNS to be more reliable, but it is exactly in the opposite case that there is concern)=20 =20=20=20 2) Once you find the CFile, according to the URL you dug up=20 (Thank you. The link in the 22 year old ID is long dead) > https://developer.mozilla.org/en-US/docs/Web/HTTP/Proxy_servers_and_t= unneling/Proxy_Auto-Configuration_PAC_file The PAC file is javascript? =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCgAdFiEEow/1qDVgAbWL2zxYcAKuwszYgEMFAmJCNEEACgkQcAKuwszY gEM6UQv+ILMEtEqfmgXVIbfSEoXGXbUQSjFXmMjKa5t0JAOWWzBdmVUJ+qZKJYkx rWV8L1qDP2G+5lPlYg7qhyMrMY7nuWUl8jWi57zfIy2GJksSZ6aVR4SdgVZRgXSw 9vAkKKcNp2no+/IX0pqpSmiTw1CKRPSy7Bq38FyMMw6dRsWzPbe487Xe42HFT6yM Ki5VxlWyrzvrGadHXZfX9r3fABbOk+xrz9RoPU5BrdJizVkBZcvGfIOumom552iD 2tDZ6HTUdOwbcpVoioieRsetYJ//KgtsTAMA5YGhfHGP8mHkMq6YDObaRs+KKKmr iBZM+Me1s/4UVzbv4fWYXx/kVqukPzBDvZPThzioVoZbjRCCOsCn+JbSMBhos7/g l9VhgHMX7j3MDBCU2EVMDRrkwBGRQnB872O85kBKPMYtk88FvArZEyi0Uk1/Vbi4 lrmzHceA4l5vuHcAhURsxHBeW+SWsp/SDUL/3wlhJ6keClD790UoRkwBBPxQAWlJ wlp3EZlG =bcDn -----END PGP SIGNATURE----- --=-=-=--