Re: [Iotops] Status update on MUD-IoT-DNS-Considerations

Eliot Lear <lear@lear.ch> Thu, 15 July 2021 23:18 UTC

Return-Path: <lear@lear.ch>
X-Original-To: iotops@ietfa.amsl.com
Delivered-To: iotops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3771B3A15D9; Thu, 15 Jul 2021 16:18:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.89
X-Spam-Level:
X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 UeNjm4z2Zh3j; Thu, 15 Jul 2021 16:18:36 -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 C9DDA3A15D0; Thu, 15 Jul 2021 16:18:35 -0700 (PDT)
Received: from Lear-Air.home (pool-173-54-226-148.nwrknj.fios.verizon.net [173.54.226.148]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 16FNIVrZ248155 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 16 Jul 2021 01:18:32 +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=1626391113; bh=SP9V50AZVcvVitkaPOYHpFJKdlQ8P/cBYVRy8iurLUo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=NEk0GtB/gQ70PBP2cgusqIHINZIoRF1XEGk8lekSfSoDsNGzmFXiXC7I8KJPoPepU PAX5oy9pOy/rSI7OY4Wxgie+k+02qHPdCKJ9D3q79yxYh2oWGmK11BXTLRgOwGk71d hP1KxEIhsykflsgvIT8NEcJgpl5CSXWGaAMpmtj4=
To: Michael Richardson <mcr@sandelman.ca>, Robert Kisteleki <robert@ripe.net>, opsawg@ietf.org, iotops@ietf.org
References: <25526.1626054262@localhost> <a3bb99b1-b575-244c-f434-9696aa5b771d@lear.ch> <f3f619a0-b8ef-882c-691f-96c70f8b04ee@ripe.net> <b02e993b-3823-b01c-8c9f-08a65eab4bfe@lear.ch> <20862.1626382966@localhost>
From: Eliot Lear <lear@lear.ch>
Message-ID: <afca8d4d-eed7-d39c-3fe2-47e43b2b5a17@lear.ch>
Date: Thu, 15 Jul 2021 19:18:30 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <20862.1626382966@localhost>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UyN44hlXYVDnkxVsUZPbZIUCpCa8jHkma"
Archived-At: <https://mailarchive.ietf.org/arch/msg/iotops/0h7gYN0TihOvZwunzYWiWJduDcY>
Subject: Re: [Iotops] Status update on MUD-IoT-DNS-Considerations
X-BeenThere: iotops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IOT Operations <iotops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iotops>, <mailto:iotops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iotops/>
List-Post: <mailto:iotops@ietf.org>
List-Help: <mailto:iotops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iotops>, <mailto:iotops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Jul 2021 23:18:42 -0000

I think the deployments also have to be somewhat forgiving in terms of 
maintaining an ACL some period beyond TTL.  It would make a good paper 
to understand just how much.

On 15.07.21 23:02, Michael Richardson wrote:
> Eliot Lear <lear@lear.ch> wrote:
>      > What is and is not a good idea is highly contextual in this case.  The
>      > network CAN provide a level of protection to limit attacks on devices, but it
>      > can only do so if it knows who that device wants to talk to.  There is no
>      > magic here.  Either the bindings can be established or they can't.
>
> Right.
> So the advice boils down to:
>
>    Dear IoT device Manufacturer,
>    if you want your device protected,
>    then avoid playing DNS games that can not be described easily MUD.
>
> ----
>
> Maybe the document would go better as a song?
>          https://www.youtube.com/watch?v=0NnzChrd0S4
>
> my new lyrics:
>
> A lonely MUD controller gazing out of the window
> Staring at a IoT device that she just can't touch
> If at any time, he's in a IoT attack, she'll be by his side
> But he doesn't realize he hurts the Internet so much
> But all the DNS-filtering just ain't helping at all
> 'Cause he can't seem to keep hisself out of 8.8.8.8
> So he goes out and he connects to the cloud the best way he knows how
> Another TLS connection laying cold in the IDS
> Listen to me
>
> [Chorus: TLC]
> Don't go chasing DNS flows
> Please stick to the servers and the stub resolvers that you're used to
> I know that you're gonna have it your way or nothing at all
> But I think you're moving too fast
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
>
>