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

Ben Schwartz <> Fri, 11 September 2020 01:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F5C83A12D5 for <>; Thu, 10 Sep 2020 18:35:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 Sl3EqoPquPqu for <>; Thu, 10 Sep 2020 18:35:45 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5EDC03A12D6 for <>; Thu, 10 Sep 2020 18:35:45 -0700 (PDT)
Received: by with SMTP id t16so7557686ilf.13 for <>; Thu, 10 Sep 2020 18:35:45 -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=W51Eh2ag3ovjwHymYjELvSqEVpi1N3vSreePnS63Ky4=; b=dkWAg7W1LT/EgsfYu/94V/wDlNJcknfodHSWNn3TvVkqQwTjvS5zKYz9iRek4xJLqN eHRO/RjQ75BjGes6DoTQcklYmM7hq0VLnzCl6H2T1hAcl6fQr0La4eGwhf8174Xiw8tP CXiabbf+gDZweyu7hJlu0oW1NfNnQuQW0oJAhD26b/i2YMciOsA8m+dMNRY7pF7gRhtk Tj6YnjJT4ek9pbr6PzVWvxYGLtL0UgFsy/JHYY86wyjB0X/hsRNNFC6aSuCPknoE1H2R /MWkIXkkoAs7Qy17ZvasS3K/lTp2f42RMgJdVbkdvQE1k4wA4R1RcRQGUVzK6R+s9XiU Chrw==
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=W51Eh2ag3ovjwHymYjELvSqEVpi1N3vSreePnS63Ky4=; b=AtDyruJS7IRl9sSXqhKWUPcGOfQtA51NlFvpvsFOm1tOjaqtDdFh1G+gJjvcBe2VWU WLpCAJzdKPDtJQgKJTaLijaQxXwDVTW8K8/vBENuNk8MyVcEIjJ508rlQBk32OFVG6zi 0EiREG+kC3a2CsNsFuo7k1Gv4/j96Lsh5FVLgKALZdFD1c+8/UQyyF6l3o7tBj5S/Li5 WjEenBDP7AoA+XNrNQENyGTrb+fq5mQhFQAVxpu4W42YFG7ZtRKpdnpIKS9O/2HnoANx ezmsCUko6VqxV0a+jAbnWZ9HMgMvgvDAwuWUTVLpBvu53r2Bf8QLSypQfA5jibHAE4R/ mvkg==
X-Gm-Message-State: AOAM532ZBHZiFRbblyXCeaje9mzRisF4t4xEzddVcDmO7xORJyWBX05q 7nDOG1xTuTGx9axBeRrOMN8WbRERg0L7Nv/TxcmCvw==
X-Google-Smtp-Source: ABdhPJwMrshmAaXxS6zvn4gaVZVL6dW/R5wIGEoqdHH7jKsZYLsvLo3atR5jmIRrli8/LhCmE3/FCwnaayePtnKNmY8=
X-Received: by 2002:a05:6e02:10d1:: with SMTP id s17mr8910243ilj.24.1599788144189; Thu, 10 Sep 2020 18:35:44 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Thu, 10 Sep 2020 21:35:33 -0400
Message-ID: <>
To: Michael Richardson <>
Cc:, "<>" <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000156ad005aeffb41d"
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 01:35:48 -0000

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.

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.

On Thu, Sep 10, 2020 at 11:47 AM Michael Richardson <>

> 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