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

tirumal reddy <> Sun, 20 September 2020 07:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DC1B03A1108 for <>; Sun, 20 Sep 2020 00:28:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Tha27sh6yi5D for <>; Sun, 20 Sep 2020 00:28:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CF1A43A1106 for <>; Sun, 20 Sep 2020 00:28:18 -0700 (PDT)
Received: by with SMTP id r9so12092766ioa.2 for <>; Sun, 20 Sep 2020 00:28:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MicLX/qOtQy3q8mRTbnLgV6NYwbCsmLxDwLqeXaQokA=; b=bsREl6eQSVcICJk9wfFOfsBTjYuahSwFmhJZAGb+B+b440oOScaUqdN/uMhT6QWpBE RGBY7koMf2hloaIi20Z54NYTFZHDysY0DsljoaRFy4DDqBr0ANJMYoZ52OM8EpBr8c7u WOWjflxlrEUVX5Fw1XmFJlbXrh5MGUGeocrHHMW9Yyqn8PTdhR9G/uwdfbEs2+UpSvL4 +C0QYEAaPbcA4ZD5tuxpjrkgVLdNC8hJYE08ZQqcQtHfr118KjCAbwktVAJBmiLhajIj wO+VcFZPtn0+I9PMYJlD9cQuQgqM19ypI7egX5SP9O9IZWCVikxSqV10hloma/oK9ynj RzWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MicLX/qOtQy3q8mRTbnLgV6NYwbCsmLxDwLqeXaQokA=; b=SaEvKP7W7vF/ugsRFxQfZxfxwtLg5deQW+K7HJx4icspqKgoU2hfCbag88CXdK17ux Mgs+Zazu+YDe7Ws8fw3cDMB40ZuYJQAPuCy09nxJWtk5RiBLSdKNcpubSsxFBtMIul/r vt/03rpNHA5bRY9XKWN60svddbChBLhgK/6Ue/4dEr1u70HbmDAKGt+bZu/oX9FmuGG5 YZKqbCPOK/DXsyYxJ/DChvZcyor4YiqX+Jkn1DZtr/mG5Iok0ysaVjFr3y7+czXpydyZ /a12vltgaSqpfjgd0snUieDHZL+DlMjtoinvtogUNA7coGTXCDvkcqJyFhFXhW09/zyK c/TA==
X-Gm-Message-State: AOAM530ogdFMjwXyCihnI9SCy0X+yvHWzbMimvs+7lNrPMEhdm7rlhIh u4hS/+aRX9tLgxhOGTjLvLOYCaE++ud3qoknowr7DU/3643+cg==
X-Google-Smtp-Source: ABdhPJxSZzPi7FIM3mFA8lJH4kEzBa1rgiWchhM9AjkqxinfeOoc1J1OY/wGPJ39hqKg95TaVR4Gw2hLtcnKOpAMp5M=
X-Received: by 2002:a6b:c8d6:: with SMTP id y205mr33164838iof.177.1600586898019; Sun, 20 Sep 2020 00:28:18 -0700 (PDT)
MIME-Version: 1.0
References: <> <7542_1599229104_5F524CB0_7542_437_16_787AE7BB302AE849A7480A190F8B93303153B299@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <>
In-Reply-To: <>
From: tirumal reddy <>
Date: Sun, 20 Sep 2020 12:58:06 +0530
Message-ID: <>
To: Michael Richardson <>
Cc: opsawg <>
Content-Type: multipart/alternative; boundary="0000000000007d1be005afb9adc1"
Archived-At: <>
Subject: Re: [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 20 Sep 2020 07:28:21 -0000

On Thu, 10 Sep 2020 at 21:21, Michael Richardson <>

> On 2020-09-04 10:18 a.m., 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.

That is exactly what we are working on till we get support from IoT

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

To handle this scenario, the default action is not to block the TLS session
but to export the network telemetry including TLS metadata for anomaly
detection using machine learning techniques (similar to


> _______________________________________________
> OPSAWG mailing list