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

tirumal reddy <> Fri, 11 September 2020 07:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 74AAD3A08C0; Fri, 11 Sep 2020 00:02:18 -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, 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 bamyacuWVEsx; Fri, 11 Sep 2020 00:02:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::141]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C86623A0895; Fri, 11 Sep 2020 00:02:15 -0700 (PDT)
Received: by with SMTP id q6so8048906ild.12; Fri, 11 Sep 2020 00:02:15 -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=gnmRHZaD0VqnC3I/gSIDYGk/0QSvW3q5nN2lSgb54iY=; b=Ma20nsuiTgXfZnY3zmJMbIyqMioQ7rHbBzu8GMCFH2u6E/cSlQTovHOoY9oUE/3e5b eGKgWkXkdl006+fo+gdqQIG884/iRDtugZAGrihAY06uWE+We1mIarppjAejy8zWOjzT hTUOFmQD+IVoyjR/KIF3yuLyOrjA9QtLC64Av/DHEYhLeeRb9NTo+3/WHK+PeHa64CI1 IxN15+Y1ipLLx78qFtH5JLv2kCusBXf7jrZsHfaEVETxI7j/NlesTqOsDWI8AqobAi/7 82je1YUzFJJG7V/YEV20dqN0zWgGhMO7H7nkdRMdY+qUAPzasDA3URoSH5YWVhfq1Q7q APyQ==
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=gnmRHZaD0VqnC3I/gSIDYGk/0QSvW3q5nN2lSgb54iY=; b=keeI10Z7Do+X0BwlRmuJh0E5h4kv+YjLhyj59nSGVqqD0N2AuIM70UPbfQXycp+PLs iOuj7GH+CkUr/C1nAOqAnTqXZhoPUKCnuc98BiTuBUjhyW9DOSFH3yuZN3z/OF3dcwbW Jyr/aHun5umLJ1NyrpzJcagKFjf51OXfMma0RL4HR9kDFviMcJxjYkVgn5IEewExOdxr 717elFhv1OqMsJun6ssysFYemCIZcFagDSqub21ryGbhjr76mu0yIGfOyxSTLRC4RjAF MwQjirxdoaCHF1kv9Un/3yIGIDfVM6nEjZFggWYbwzafmYoqdXQJbdSJiu/ExUdadtlY wCQA==
X-Gm-Message-State: AOAM530QIhBXAVEWeBARc9ZabWe4R7tlCow5g9S0/k5Q8+1Cua7WIqCp BvYGDz0T3JjPchiJa3vfXfAWgHU01dK+TCjVsTD/nT4DD4djUg0e
X-Google-Smtp-Source: ABdhPJzdoTdTe93gxaBDF9i+ux06Lh5wvyoVBQISZKq+0K5T7NO9iXJ86UzI5MLqulopARamhxjE5Ty6wshxX3Gad/U=
X-Received: by 2002:a92:1908:: with SMTP id 8mr684519ilz.214.1599807734985; Fri, 11 Sep 2020 00:02:14 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: tirumal reddy <>
Date: Fri, 11 Sep 2020 12:32:03 +0530
Message-ID: <>
To: Ben Schwartz <>
Cc: Michael Richardson <>, opsawg <>, "<>" <>
Content-Type: multipart/alternative; boundary="000000000000c0ba1d05af0443ba"
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: Fri, 11 Sep 2020 07:02:19 -0000

Hi Ben,

Please see inline

On Fri, 11 Sep 2020 at 07:05, Ben Schwartz <bemasc=> wrote:

> Thanks for highlighting this, Michael.  I don't support adoption of this
> draft, because I don't think it is fit-for-purpose.  Specifically, I think
> it is likely to provide a significant advantage to malware authors (the
> opposite of the intended effect).
> Currently, if a malware author wants to match the TLS characteristics of
> the host device, they have to do some work to characterize its TLS
> behavior.  This may be difficult, especially in the case of partial
> compromise, or for malware that targets a wide variety of hosts.  However,
> with this MUD module in place, the malware can read the TLS behavior right
> out of the MUD profile, and configure its behavior to match.

The MUD URL is encrypted and shared only with the authorized components in
the network. An  attacker cannot read the MUD URL and identify the IoT
device. Otherwise, it provides the attacker with guidance on what
vulnerabilities may be present on the IoT device.

> Note that, except in the case of TLS termination, the proxy cannot verify
> anything about the TLS session by observing it.  Just because a connection
> appears to use a particular SNI or certificate does not prove anything
> about the actual destination.

Yes, it is discussed in


> On Thu, Sep 10, 2020 at 11:47 AM Michael Richardson <>
> wrote:
>> On 2020-09-02 11:05 a.m., Joe Clarke (jclarke) wrote:
>> > Hello, opsawg.  This draft as underwent a number of revisions based on
>> reviews and presentations at the last few IETF meetings.  The authors feel
>> they have addressed the issues and concerns from the WG in their latest
>> posted -05 revision.  As a reminder, this document describes how to use
>> (D)TLS profile parameters with MUD to expose potential unauthorized
>> software or malware on an endpoint.
>> >
>> > To that end, this serves as a two-week call for adoption for this
>> work.  Please reply with your support and/or comments by September 16, 2020.
>> I have read the document in a number of different revisions, and I
>> support adoption.
>> I have been concerned that this document codifies a kind of TLS snooping
>> by middle boxes which has in the past caused significant harm to
>> development of TLS. (In particular, TLS version negotiation has had to
>> evade existing middle box policies!)
>> However,  this document seems to walk the fine line between causing
>> protocol ossification and providing real security.  To the extent that
>> it reduces the pressure by enterprises to invade the TLS encryption
>> envelope through use of Enterprise certificates [is there a term for the
>> activity describe in section 4.1? I wish there was] this document is a
>> very useful thing.
>> I would like to suggest that upon adoption, that this document go
>> through a TLS WG review of some sort before OPSAWG does a WGLC.
>> _______________________________________________
>> TLS mailing list
> _______________________________________________
> OPSAWG mailing list