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

Michael Richardson <> Fri, 18 September 2020 22:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 372C63A098D; Fri, 18 Sep 2020 15:12:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0w2cSF4l7KTQ; Fri, 18 Sep 2020 15:12:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D3FFC3A005C; Fri, 18 Sep 2020 15:12:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id 678EC1F4A9; Fri, 18 Sep 2020 22:12:52 +0000 (UTC)
Received: by (Postfix, from userid 179) id 439131A022D; Fri, 18 Sep 2020 18:12:51 -0400 (EDT)
From: Michael Richardson <>
To: Eric Rescorla <>, "<>" <>, opsawg <>
In-reply-to: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <CACd> <>
Comments: In-reply-to Eric Rescorla <> message dated "Wed, 16 Sep 2020 14:02:29 -0700."
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Fri, 18 Sep 2020 18:12:51 -0400
Message-ID: <107735.1600467171@dooku>
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, 18 Sep 2020 22:12:56 -0000

ekr> Taking a step back from details, ISTM that the whole design of this
ekr> document is antithetical to extensibility:

I agree.  It was my first reaction as well.
I then had another thought: there are dozens of entities out there that want
to do this regardless, enough that it broke the TLS version system requiring
the hack. (Does that hack have a name?)

We can call them stupid, or we can try to understand their point of view, and
try to help them be less stupid.  

ekr> TLS is a protocol with a number of extension points. What this document
ekr> does is allow an endpoint to restrict its use of a certain set of
ekr> extension points. However, the language provided here is insufficiently
ekr> rich to allow the client to properly describe the use of those
ekr> points.

assuming that some language could be provided that was sufficiently rich,
would your objection continue to stand?

ekr> As a concrete example: for extensions the model knows about
ekr> (e.g., supported_versions) you can indicate the contents of the
ekr> extension, but for extensions the model does not know about (e.g., ECH)
ekr> you cannot. That means that you're either stuck with allowing anything
ekr> in those extensions (which means that your filtering effectiveness is
ekr> reduced) or you don't allow those extensions, in which case you create ossification.

ekr> As a thought example, consider a hypothetical TLS 1.4 which decided to
ekr> adopt QUIC-style obfuscation of the CH and SH, putting the obfuscated
ekr> CH/SH in extensions in a stereotyped outer CH/SH. The system described
ekr> here would be unable to do anything useful with that, which creates
ekr> pressure to block TLS 1.4 entirely, which obviously is not awesome.

I believe that without a mechanism described in this document, many
enterprises may conclude that they need to block TLS 1.3.

ekr> If we want to pursue this kind of idea -- and I'm not at all sure we
ekr> should -- ISTM that rather than trying to invent some new DSL for
ekr> filtering TLS we allow the client (who by hypothesis is trusted as to
ekr> what it will generate) to provide a general program that the middlebox
ekr> can interpret that will describe what it will do. For instance, you
ekr> could provide a WASM file which gets fed the CH and just says "this is
ekr> me" or "this doesn't look like me". That way we don't need to continue
ekr> extending the language here whenever TLS evolves. Note that that doesn't
ekr> prohibit having a language like this as a programming convenience, but
ekr> it wouldn't restrict the semantics of what you could say about the
ekr> connection.

We don't have to have the client provide it, it can be encoded by the
manufacturer in the MUD file, assuming that it depends upon the model, not
some local decision in the client.   The idea of having a WASM file is an
interesting one, but being an executable of a sort, it has other security

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