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

Eric Rescorla <> Mon, 14 September 2020 17:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D1B783A0AA1 for <>; Mon, 14 Sep 2020 10:23:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 BmnRI-BYchz7 for <>; Mon, 14 Sep 2020 10:23:34 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BA4CA3A0A9D for <>; Mon, 14 Sep 2020 10:23:33 -0700 (PDT)
Received: by with SMTP id z17so72911lfi.12 for <>; Mon, 14 Sep 2020 10:23:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8OsLWRdwRA8cy1zuMLqMvUxJtZGlZ1L+0hRAJljjR90=; b=DGJ2MLixR8+XSSXWpDYpqDMnJZ2xRAmFmWPOe5bDc6v6LDOcba3WUdWiQ1rT92llmx m5s6AW4vfBEgysy1X7ryWYhF6jBATPaM+RgBegjOz4//d4zPGVgPzA/GJKY/KOzrtGep IbU9hP5aRxCSUmRs+2Y7FRIgWFTzHFDli/3Bn9Qn2VEJbc/rAgjCdH6uC1Co14gpOD3c YbD/Y3IkgHSn7U7wjfjpbDQtIHo339ZpI87TmeHCXiAFFR5GiOHmU8hNqBUZZKNsSfMD gKew/zWBbXJj8I6lT2aaW2pu0yG6V8BIkrIscAeV8uHxJCL62iRPmVA+h9MvMq9xKQHZ naaQ==
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=8OsLWRdwRA8cy1zuMLqMvUxJtZGlZ1L+0hRAJljjR90=; b=oCFtGU6FLN5ayLFT3oPv0LOGK57BlpaiL+YhKLS7iqwpILFy4+/lKUNQJvBGh95W5X +TwFCt92dk+YpR2ci6vv/H4Y8kO+HUw3fQKoZdQ3uLfGOb36OQEejlTD01tTJzmRi7Dl ySUmQgBbD7LJ4DNIYFtKsJCUXl73Q5LMOicC9jZaWst5/kjAvGGewA+Nm5LM4IrOmmgf fTnfIBTeGJM25xVQbA5rQYGAAG7+Lh4FUNo6z/SrZUfu8Ea0jpaeqFYJb8WOpd6ahkSQ vXAUo1vTitDJ7kHwpKYYI7mPGi3fORRo7X9wt7wYEoQFgtEIIFzbqIo4VSCSNQWSp6pG r5fw==
X-Gm-Message-State: AOAM532eNphU+HSkNakCMixt8jWu1UJ08/CsTCqfrVE17RfYomSajhwU LQ09rN0ZkiBPV/Amqapfdy8+qHHIOQu8/L+ySJgTOw==
X-Google-Smtp-Source: ABdhPJye3Pv6bcVhnQrd+Oa83AStcPuDgvL+rwV2mX6XRFPpqVo056DuFnGKA+gyetAWbfA7B9orfKALz22A2IZqgYc=
X-Received: by 2002:a19:604e:: with SMTP id p14mr4457332lfk.385.1600104211821; Mon, 14 Sep 2020 10:23:31 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Mon, 14 Sep 2020 10:22:55 -0700
Message-ID: <>
To: Ben Schwartz <>
Cc: Michael Richardson <>,, "<>" <>
Content-Type: multipart/alternative; boundary="00000000000026487005af494b34"
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: Mon, 14 Sep 2020 17:23:36 -0000

I tend to agree with Ben Schwartz on this. I have two
concerns about this draft:

1. It seems likely that it will lead to ossification. While
it is true that devices can in theory update their MUD
descriptions, as a practical matter expecting middleboxes
to enforce certain properties of the TLS handshake seems
likely to mean that they will not do a good job with
unknown data. For instance, this document specifies ways
to describe:

(1) a list of supported extensions types

(2) the expected contents of certain extensions (e.g.,
    named groups)

But what happens when a new extension type is created?
It seems fairly optimistic to think that middleboxes
will just accept whatever stuff the client generates
as long as it's one of the listed code points.

2. This document seems to encourage the use
of terminating (MITM) forward proxies (in Section 4.1).
In the past, the IETF has explicitly avoided endorsing
this practice.


On Thu, Sep 10, 2020 at 6:36 PM 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.
> 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 <>
> 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
> _______________________________________________
> TLS mailing list