Re: [OPSAWG] New Version Notification for draft-reddy-opsawg-mud-tls-02.txt

tirumal reddy <> Wed, 22 January 2020 15:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 38D3B12010C for <>; Wed, 22 Jan 2020 07:08:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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] 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 vf_D0lKfVMGa for <>; Wed, 22 Jan 2020 07:08:13 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A66D412010E for <>; Wed, 22 Jan 2020 07:08:13 -0800 (PST)
Received: by with SMTP id x1so6933990iop.7 for <>; Wed, 22 Jan 2020 07:08:13 -0800 (PST)
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=ZE5TFWTxXGWfmv4QZjINyhwkjhMqczrbKoAkVg8BsdY=; b=cHY0cVACvmoYoTgZZ9W+VeT3zaL2PcLqz6TQG3meO+6mKbRvv29+UN4AIfMO2srbBn B+gCRMEC5mb7Q8C7CYUlYC9Bo9ailj0bZx65fhX7nQ3NlYG3jUwPa0NzkALXtxtuj+TB ys0RVSd/pdeDS8wUTD2/Zt60FPj5UwagcKSPpaojA7cOejQqQ9qb4rjwXwAiif8X9cle AkmC0LQ6lUDg/DGSBrOnRxQN1dhUTsZr9wy+/MLjxCTbAUhCCA9fI8NdyZCadabqsEFY ZTaUkS/XHtIpi0l335hSrpL70V/uq48zsg40V3tPnd6RbW5QbuEn067SblEr8BUhy38m i5RQ==
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=ZE5TFWTxXGWfmv4QZjINyhwkjhMqczrbKoAkVg8BsdY=; b=UjJ8IKTkYF28xnhLhxiSw8oq1sG1bpgfnu6OfLlaaGxpcUqgxXdQ6rgon9O7lL2qSN hkLHsgHir9v2NCYmzLpKbLGbBXGk8pvftM62n1oFW+IQ+qXuszGfPoqP/x4iTWRF3IBe jqStRcRNZ6iAkKEUYm73GJO6ZR3ojbAQrEZu8E6d88b723E7FdtdrNfJsVoy+S9mI7bc K0QqbJW817QzuYr6FNlp0+Y1SX/yAgPjkRAQD9cWzfXIfSsFuw7mRqmGlLtqxluDHLod yOgwYVc3zaxYK3poDRtSAYUQgF83Zwzf0FEE6XpG9E71U6KGmJzJGtCxdQcWnT+6alrj d3qQ==
X-Gm-Message-State: APjAAAWIzYm+eaaqaqmqLDTi/dGORZvKthaWNrWCGXdhtHvo09ZVBPep 6PWLcbsFd3g362nbgep2fA4+gM2KtGBUIvNFmb5aeN+u
X-Google-Smtp-Source: APXvYqwLdU2ZK02gIxf9q8cAW5A7NlFSr333sAHh4CFo4s85VnZNe9aCDbiZMKLWs9qDua4hEeevb4CpaN8vHehG9os=
X-Received: by 2002:a6b:e30e:: with SMTP id u14mr7419062ioc.242.1579705692929; Wed, 22 Jan 2020 07:08:12 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <20570.1579314460@localhost> <> <6891.1579656958@localhost>
In-Reply-To: <6891.1579656958@localhost>
From: tirumal reddy <>
Date: Wed, 22 Jan 2020 20:38:00 +0530
Message-ID: <>
To: Michael Richardson <>
Content-Type: multipart/alternative; boundary="000000000000ad4434059cbbe45c"
Archived-At: <>
Subject: Re: [OPSAWG] New Version Notification for draft-reddy-opsawg-mud-tls-02.txt
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: Wed, 22 Jan 2020 15:08:16 -0000

Hi Michael,

Please see inline

On Wed, 22 Jan 2020 at 07:05, Michael Richardson <>

> tirumal reddy <> wrote:
>     > No, the proposed mechanism will help identify the presence of
>     > unauthorized software or malware on an IoT device.
> I understand that there is a lot of prior art and industry experience doing
> this.  A lot of people are quite upset about how these things have
> progressed, but it is not my purpose to tell people how they can or can't
> run
> their network.  It's not my point to argue here.
> I am actually in favour of end-to-end authentication and hop-by-hop
> encryption, permitting controlled and clearly authorized auditing.

Glad to see we are in the same page :)

> I even wrote draft on this topic in 1996.... (for IPsec)
>     mcr> 2) it seems that manufacturers might be able to say, "HANDS OFF"
>     mcr> to IDS systems. (perhaps avoiding use of more colourful language)
>     > Network security vendors offering firewalls/IPS to enterprise
> networks
>     > already have the capability of performing
>     > TLS handshake inspection and acting as a TLS proxy, they can leverage
>     > the proposed mechanism.
> It will be easier for vendors to avoid interposing themselves on
> communications that would present legal problems if this extension can
> clearly say hands-off.

I don't get the comment. The decision whether to deploy a TLS proxy for the
IoT devices/endpoints is up to the organization owning them. The TLS proxy
has to meet the organization security and privacy requirements. Further,
middle box administrator configure the firewall to bypass
traffic decryption for a connection destined to a specific service due to
privacy compliance requirements.

Malware identified last year is using DoH to hide the DNS messages from
passive monitoring (see (
and such malware communication cannot be detected by DNS based filtering,
malware agents will not use the DoH/DoT server provided by local network,
TLS profile parameters can be used to detect malware communication with C&C
server for IoT devices with broad communication patterns.

As you may already know, Windows recently had a vulnerability in the
certificate validation function and would accept spoofed certificates
certificates (you can image the problems with IoT devices). Samsung fridge (
accepted spoofed certificates because it failed to validate the server
certificate (imagine the problems with off-the IoT devices, see

>     > Middle boxes from several security vendors acting as TLS proxies do
>     > keep up with the updates to protocols
> Well, it's never the good actors that cause the problem.
> It's the bad ones :-)

I don't think organizations who care about security and privacy, and most
importantly their reputation and business will deploy such bad TLS proxies.

>     > In any case, it's not BRSKI that matters, but EST(RFC7030)'s
> /cacerts.
>     > I see that it's probably difficult to get to RFC7030 just to run
> /cacerts,
>     > but if BRSKI is being used already. {If this gets better IoT
> onboarding into
>     > Enterprises.... well. What a Faustian bargin...}
>     > I believe that attempting to auto-configure a TLS 1.3 MITM proxy
> using EST is
>     > a really bad idea. Devices that are willing to fall prey to such a
> The problem here is that the EST mechanism as envisioned by BRSKI is not
> intended to be a general trust anchor, but rather to validate items that
> are
> within the same domain.

I just don't think that this is a good way to introduce alternate trust

roots.  My recommendation is that you go ahead with the MUD profile that
> describes TLS profiles, without tying that to TLS proxy mechanisms.

Got it, thanks; updated draft to say the mechanism to configure the IoT
device with the middlebox's CA certificate is out of scope.

>     mcr> Additional, it is entirely reasonable (perhaps, given MITM
> attacks!) for an IoT
>     mcr> device manufacturer to "call home" using a baked in, non-public,
> trust
>     mcr> anchor. Such a situation would be indiguishable from malware
> calling C&C
>     mcr> using a baked-in trust anchor.
>     mcr> I would certainly want to do this for firmware updates.
>     > I don't get your comment. How will malware's command and control
> server
>     > certificate be signed by the baked-in
>     > non-public trust anchor on the IoT device ?
> The malware will include it's own non-public trust-anchor.

If malware uses it's own non-public trust-anchor, it will be detected by
the TLS profile (acceptlist-ta-certs and SPKI-pin-sets) and the
malware flow will be blocked.

>     mcr> Given that MUD can clearly control where connections are made, it
> seems to
>     mcr> me that much of this effort is a mis-guided relic of pre-MUD DPI
> IDS systems.
> The point here is that MUD can keep the malware infected device from
> calling
> the C&C server completely.  We don't have to do TLS profiling to detect
> that connection.

I don't get your response. MUD cannot be used to detect communication with
a C&C server for IoT devices with broad communication patterns. Further,
the malware agent may not do a DNS lookup (for example, I have seen malware
agents that obtain the C&C IP addresses as part of random text served from
established information source (e.g. websites such as blogs)) OR malware
using DoH to hide DNS messages OR malware using privacy enhancing
technologies like Tor (no DNS lookup is required).

>     > No, we are using MUD for IoT devices in our product
>     > but as you already
>     > know MUD is not suitable for IoT devices with broad communication
>     > pattern. TLS profile parameters can be used
>     > on such devices to permit intended TLS use and block malicious TLS
>     > use.
> I understand this use --- for broad communication patterns.
> I think that my document draft-richardson-opsawg-mud-acceptable-urls might
> help with rapidly updating TLS profile info as new firmware is updated.

Yes, Thanks.


> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT
> architect   [
> ]        |   ruby on
> rails    [