IETF Logo Mail Archive

Re: [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 10 September 2020 15:51 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 D9B693A0B7E for <opsawg@ietfa.amsl.com>; Thu, 10 Sep 2020 08:51:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.847
X-Spam-Level:
X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 K01RTwZWy29H for <opsawg@ietfa.amsl.com>; Thu, 10 Sep 2020 08:51:17 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A8DD3A0BD6 for <opsawg@ietf.org>; Thu, 10 Sep 2020 08:51:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 6B8C6389D8 for <opsawg@ietf.org>; Thu, 10 Sep 2020 11:30:04 -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 S5_PJj-yHq4G for <opsawg@ietf.org>; Thu, 10 Sep 2020 11:30:04 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D5DBA389B3 for <opsawg@ietf.org>; Thu, 10 Sep 2020 11:30:03 -0400 (EDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5E03D212 for <opsawg@ietf.org>; Thu, 10 Sep 2020 11:51:15 -0400 (EDT)
To: opsawg@ietf.org
References: <21BA8D05-DD83-44DE-81B9-457692484CAD@cisco.com> <7542_1599229104_5F524CB0_7542_437_16_787AE7BB302AE849A7480A190F8B93303153B299@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: Michael Richardson <mcr+ietf@sandelman.ca>
Message-ID: <7846ca6e-a0a6-9a8a-f163-703995fa496e@sandelman.ca>
Date: Thu, 10 Sep 2020 11:51:15 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <7542_1599229104_5F524CB0_7542_437_16_787AE7BB302AE849A7480A190F8B93303153B299@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/_nxupEEGzAV1Qn7qj63vZ5vT_Ko>
Subject: Re: [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
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: Thu, 10 Sep 2020 15:51:19 -0000

On 2020-09-04 10:18 a.m., mohamed.boucadair@orange.com wrote:
> Hi all,
...
> It would be fair to include some of the limitations of the proposed approach (e.g., IoT devices that are not maintained).

IoT devices which never get software updates would benefit greatly from 
additional protection that MUD provides.  A MUD profile for such a 
device would have to be created by a third party, and one way to do this 
is by observation of current traffic.    That could certainly include 
TLS parameters observed.
There are multiple efforts in this direction, and additional 
coordination is probably desirable.

Since the device is not getting updates, it won't be changing it's TLS 
library, and so the mechanisms that are described in this document will 
be even MORE effective.   So I'm not sure what limitations you are 
thinking about here.

The real risk is that the device suddenly receives an update, and since 
the MUD file is not from the manufacturer, that the device now sets of 
alarms as the MUD file has not been updated.

v2.23.0 | Report a Bug | By Email