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

tirumal reddy <> Tue, 15 September 2020 10:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B6103A0C55; Tue, 15 Sep 2020 03:45:16 -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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mSggOMwRiFty; Tue, 15 Sep 2020 03:45:14 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 07FDC3A0C4F; Tue, 15 Sep 2020 03:45:14 -0700 (PDT)
Received: by with SMTP id z13so3488192iom.8; Tue, 15 Sep 2020 03:45:13 -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=y1V9BvnWT95XivR7FlJ9tuo/g6A/KmZB50NbWeR6ji0=; b=q3WgVXXTZJrmTui6nySSda37CjYmR8siUwAl09WrQlgBV3LzLwR8qe1sNiJUUg2tWL lSkEbUeyosgVfxYbwq4oyN38PWZHBe35FFZhSwzSPyghCU+rli4ORZbNjK1BS2imNPQk SfOO5be/MZb1ygDuwvsVSTFjfGZhsHQFXB/d5MYlh9GC1uREMQ4FowFSHYd2Wp9wh5AQ sBO6EuCK8vNgTixBpKhNggHFZUYe95Kb/CqE0hyLb1CBO2O7LYT52bn7rskpeqZhHQkN smGwJVsJOSRcZ6kCv3aqZdSb08dRegvhwKAnqRk2CJB7hs9+cO0jDid40G5aIOC++Ywy UfdA==
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=y1V9BvnWT95XivR7FlJ9tuo/g6A/KmZB50NbWeR6ji0=; b=QG3GEXm08Bhr0hAPsQ6lMTOKhC8tiHp7KJi7n23Rxxc/om9TpMqkXt7Dk2HUOG8VIi FYJh44bAVC4b2+GHZTsIWcT2BMO0iSQWLSOaa4bC1qOqT+WI/xjzleK6bCdaUgzyTARl XG9aUzixCvogKzh79pxCh0igQse1+xxISdD/RE4ZIVHZP9QXoClrplCHpaDlTEwW7i8L NyLCKtHvwus8CM7eoqhX2Y+s/O9o0L5f5wxznQkpElxPo4Ro9ROp9t/xTeJ9kQSYKzHe j+lZpuhpJPoKmLA4C3uxsV9YcQEHhL4VVJfvucCpMKoZ3RDx719B/IIDvBBMfbYfysXa UMvQ==
X-Gm-Message-State: AOAM531ijPNsn9MHoPI9SSGqnk/+OT910prIDBeF4TRXrXQzffh/xZ+q izepspxcq/kdvVgmWo7+mB3cVBySBEB6wPlyaXo=
X-Google-Smtp-Source: ABdhPJzbeMxt8tI/Y0om0reKGPqL0xlEbOwqXET9QWfNSiLawPYTM00aRNsEXSOcCNXex3JsQK0Q1kxSY2G1vhCmXfs=
X-Received: by 2002:a02:8802:: with SMTP id r2mr17565117jai.75.1600166713101; Tue, 15 Sep 2020 03:45:13 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: tirumal reddy <>
Date: Tue, 15 Sep 2020 16:15:01 +0530
Message-ID: <>
To: Eliot Lear <>
Cc: Ben Schwartz <>, Nick Lamb <>, opsawg <>, "<>" <>
Content-Type: multipart/alternative; boundary="00000000000084120705af57d87d"
Archived-At: <>
Subject: Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Sep 2020 10:45:16 -0000

Thanks Ben and Eliot for the feedback. Please see inline

On Tue, 15 Sep 2020 at 14:51, Eliot Lear <> wrote:

> Hi Ben
> Thanks for the response.  Please see below.
> >
> > Agreed ... but this proposal appears to be predicated on a contrary
> assumption.  It assumes that it is difficult for malware to learn the TLS
> profile of the device, and then proceeds to place this profile information
> in the (public) MUD file, where malware can easily retrieve it.
> Ok, I didn’t take that from this discussion.

I see the confusion, will try to clarify the issues raised:

a) The MUD URL includes privacy sensitive device details like (device type
and firmware version), and it should be stored in a secure location (like
TEE to avoid exposure to an unauthorized software) and to avoid sending
the MUD URL in clear text otherwise it will help an attacker to exploit a
vulnerability on the IoT device. It is already discussed in RFC8520.

b) One of the comments is that an attacker can observe the traffic from the
IoT device, learn the TLS profile and try to mimic some of the TLS profile
parameters of legitimate clients. This attack is discussed in detail in
Sections 3 and 5.  Please have a look.

c) The proposed mechanism not only helps detecting malware but also helps
identifying TLS and cryptographic vulnerabilities on the IoT device (to
prevent the device from getting compromised in the first place).

> >
> > I'm not thinking of the hours-days timescale of MUD file updates; I'm
> thinking of the months-years timescale of updating standards to support new
> features.  How long does a device have to wait after a new protocol
> revision comes out before it can start using the new protocol?
> Ok, I see what you are saying.  Thanks for getting me there.
> The question is what to do when you start seeing something you don’t
> understand.  Let’s take a TLS extension, for instance.  If the TLS
> extension is unknown to the f/w but is declared somehow, that tells the
> firewall that they have some coding to do, and should be conservative about
> complaining over something that is out of profile.


> I don’t see that as a show stopper.  What I do see as a showstopper would
> be if, as is written and you rightly observe, a new rev of a YANG model is
> required to introduce the TLS extension, so that part would need to be
> described in a more flexible manner (e.g, an IANA registration or
> similar).  I’d suggest the authors consider that.

Agreed, the YANG model relies on IANA for TLS parameters values including
extension type values. Even if a f/w does not support a new extension, it
can still identify whether the new extension is included in the MUD
profile. If the extension is not included in the MUD profile, presence of
unauthorized software is detected.

We will update the draft to make it more clear.


> Eliot