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

Michael Richardson <> Wed, 22 January 2020 01:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E5A9612002F for <>; Tue, 21 Jan 2020 17:36:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E_Tk7UYE36hI for <>; Tue, 21 Jan 2020 17:36:00 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 639AD120013 for <>; Tue, 21 Jan 2020 17:35:59 -0800 (PST)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 248A23897E; Tue, 21 Jan 2020 20:35:26 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 12F17E99; Tue, 21 Jan 2020 20:35:58 -0500 (EST)
From: Michael Richardson <>
To: tirumal reddy <>
In-Reply-To: <>
References: <> <> <> <20570.1579314460@localhost> <>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Tue, 21 Jan 2020 20:35:58 -0500
Message-ID: <6891.1579656958@localhost>
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 01:36:03 -0000

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

    > 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 :-)

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

    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.

    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.

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

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